Posts Tagged ‘Fowler’

Spring.NET looks to be a great way to implement some best practices such as DI and AOP while letting someone else (Spring.NET) take care of the grunt work. Unfortunately, I can’t seem to find very good sample code, and I’ve read comments about it being “overly complicated”. Then again, that makes it sound just like my sort of thing!

Led and sustained by SpringSource, Spring.NET is an open source application framework that makes building enterprise .NET applications easier. Providing components based on proven design patterns that can be integrated into all tiers of your application architecture, Spring helps increase development productivity and improve application quality and performance.

Please read the overview for additional information.

via Spring.NET – Application Framework.


Read Full Post »

I know I’m certainly guilty of this. I treat the domain model simply like a means of accessing the database and build all the real logic into a set of “managers” that manipulate the entities and do the actual work.

How does the idea of a rich domain model intersect with the Entity Framework? Sure you’ve got the partial entity classes to add your own logic and maybe I’m old fashioned but it makes me real nervous having my code tightly coupled (does it get much tighter coupled than a partial class?) with thousands of lines of generated code. Feels much safer to group the generated code in one place and your own code in a separate place so that changing one affects the other as little as possible.

That said I’ve found listening to Folwer to be a pretty safe bet, so what am I missing?

The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters. Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects. Instead there are a set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data.

via MF Bliki: AnemicDomainModel.

Read Full Post »