2

I was watching a lecture/conference speaker talking about reducing redundant code, when going from Service to Model in an Anemic model vs. the Rich model. But regardless of which I use, I end up with similar to same logic in my classes either way.

Whether I have:

ServiceX.AddName("Johnny");

or

Customer.AddName("Johnny");

I still have some database operation that I will inevitably use somewhere else that does a SELECT or INSERT with close to the same code, Anemic or Rich, in a Service or in the regular old OOP Class with behavior. I have an extra class for the service abstraction, but other than that I have the same code.

I have read the pros and cons and all that. I am not arguing one way or the other. I've done both. I will say the "Rich" one looks like textbooks and OOP, but I digress.

Does a Rich Domain Model (vs Anemic) reduce duplicate code?

Edit: Removed boilerplate code references.

|improve this question
  • I guess because to me boilerplate meant CRUD operations or something like it, over and over. – johnny Jul 14 '17 at 19:29
  • Have you tried to use a modern ORM Framework, like Entity Framework or something like it? – T. Sar Jul 14 '17 at 19:36
  • Yes. I have used them. I should probably remove boilerplate from the question. It is confusing people. Edit: I removed it. – johnny Jul 14 '17 at 19:43
3

No.

I went though an example service/class both ways and posted questions to this site with full code. It works out about the same either way.

ie. you end up with the exact same code. its just in different name spaces

|improve this answer
6

The discussion of "anemic models" vs. "rich models" has nothing to do with duplicate code, and only a few things with boilerplate code. As you already mentioned by yourself, the "core" code of your operations (for example, the SQL code for CRUD operations) will be the same. Of course, in an "anemic model", you will always need extra service classes, and the code for theses classes can be seen as "boilerplate code".

However, if it is better or worse to have this extra code is highly opinionated and may heavily depend on the individual situation. Note further, avoiding code duplication is only one measure for good code - in the discussion of "anemic models" vs. "rich models" there are other things in focus, like the SRP, cohesion and coupling, encapsulation and testability.

|improve this answer
  • 2
    +1 for "Note further, avoiding code duplication is only one measure for good code" alone (can't give more than +1 though, so it applies to the rest of the answer too). In my experience "DRY is the enemy of decoupling", so it's definitely the be-all and end-all of coding rules. – David Arno Jul 14 '17 at 20:28
  • Oops, that should read "it's definitely not the be-all and end-all..." – David Arno Jul 14 '17 at 20:50
  • If core code of your application is CRUD. Any modelling effort beyond the bare minimum is a waste by definition. – abuzittin gillifirca Jul 17 '17 at 6:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.