Marcel Popescu

From this comment : I seem to be known to many of those around me as an all around nice guy, a good guy even. But I'm an asshole, a self-absorbed prick. (...) I often find that I'm doing good things out of an awareness that I should want to do them, than because I actually feel that desire. This could have been written by me. Ouch.

Many times during the lifetime of a project I find myself writing something like this: method A(){ ... var something = B(); ... } method B(){ ... var somethingElse = C(); ... } It doesn't take long to realize that this could be written in a different way: method A(){ ... var somethingElse = C(); var something = B(somethingElse); ... } method B(somethingElse){ ... } The problem is - which way should I prefer? Which way is "better"? I have struggled with this for a while now. Today I just realized something: SRP (as applied to methods) says each method should only have one reason to change. (I was reading this article when I had this epiphany.) If something changes in C(), that effect will "ripple" to both B and A in the first case. In the second case, it is much more likely that it will only affect A. Which is fine - it is A's responsibility to "join together" the two other methods, so it's ok if it's affected by them....

1 Cor 6:12 "Everything is permissible for me" — but not everything is beneficial. "Everything is permissible for me" — but I will not be mastered by anything.

I worked on a crapload of small ASP.NET projects where I spent a lot of time on user management: add users, edit users, change roles, verify roles and so on. This includes tiny projects like a tiny website where the content of about 10 pages can be edited by the customer (mostly by adding news). They'll never have more than one person doing these edits, their primary business is totally unrelated to computers. Well, I was reading this article by Scott Hanselman and what do I see: Does it need an administrative console?, I ask. He says that'd be nice, but it wasn't spec'ed out. He figured this would be pretty low rent. The client even suggested (gasp) that they could just maintain a local XML file. How on Earth can I be so stupid? I always knew that ASP.NET had this feature... it just never crossed my mind to use it. Dammit.

Great article here . I hate the programmers dragging the certification bogey-man every time they have a problem with someone's code. Yeah, we really want to have the problems of the medical field. This article is a breath of fresh air.

From Inversion of Control Containers and the Dependency Injection pattern by Martin Fowler: The choice between Service Locator and Dependency Injection is less important than the principle of separating service configuration from the use of services within an application. Ha! :P

Follow-up to this . This is the structure I've settled on for the time being: View Controller Service Model Repository Data layer (eg, Linq to SQL) Data storage (eg, SQL database) The View, Controller and Service communicate through DTOs (aka ViewModels); the View and Controller never see the (domain) Models. I'm not 100% decided about the Service - Repository interface: should the Model objects be the same as the Data Layer objects? For purity reasons I'd say no - it's a bad idea to return Linq to Sql objects to the Service because it will cause problems when trying to switch to (say) Entity Framework. However, I haven't yet worked on a project big enough that the benefits of this separation outweigh the drawback of creating 3 different classes for the same entity (Linq Order, Model Order, DTO Order). I'll have to see what happens when I actually do work on a larger project (with this architecture I mean, I work on huge projects but not with this structure). Th...