4

I'm trying to build my first CRUD application, and I don't understand if I should use an object containing getters and setters separated.

Considering that we have the Zend Framework Quick Start tutorial with a Model structure containing:

  • Gateway
  • DataMapper
  • Domain Object (model class)

If the Domain Object (as presented on Zend Quick Start Tutorial) consists of only getters and setters, is that an anti-pattern? In a sense, we are unecessarily dividing the domain object with a transaction script?

Please advise.

Sled
  • 18,541
  • 27
  • 119
  • 168
MEM
  • 30,529
  • 42
  • 121
  • 191

2 Answers2

3

The Anemic Domain Model is an Anti-Patern ONLY IF you are trying to build a true Domain Model (aka Domain Model from Domain Driven Design) and end up with entities with only state and without behavior.

For a simple CRUD application an anemic domain model is probably a best practice, especially when you have framework that makes your job very easy.

See Martin Fowler's article about Anemic Domain Model and also Greg Young's Article.

Iulian Margarintescu
  • 2,656
  • 21
  • 22
  • So, we have two senses for Domain Models ? On once sense, the Zf quick tutorial sense, telling us that: 1) domain model (by referring to a model class, representing a domain object ?) 2) Domain Model in a sense of Domain Driven Design pattern ? I'm asking this, because on the link provided, you can see the statement that, that getter and setter class is first considered as a "Domain Model" and later as a "Domain Object"... – MEM May 03 '11 at 11:35
  • Objects are created from the model – DarkLeafyGreen May 03 '11 at 11:41
  • @ArtWorkAD: Hmm... so, we should NOT say: "Domain model refers to a model class that represents a domain object" but we should instead say: "Domain Model as some model classes (classes on the M part of an MVC) and those classes are responsable for creating "domain objects". Is that it? Arrrhhh!! Please have patience with me. :)) – MEM May 03 '11 at 11:46
  • 1
    You have a domain of interest and you describe it with conceptual models. If this would be a role play, we would create objects from the model. The model itself gives the structure about what an object could do or what information it should hold and provide. – DarkLeafyGreen May 03 '11 at 11:53
  • 1
    @MEM: A Domain Model is a generic term for the set of classes that you write trying to translate the conceptual model of the problem you are solving into code. This Domain Model can be anemic or not. When doing DDD you have a set of rules/guides that you should follow when defining your model - one of them being to not have anemic entities ( no behavior ). In the end i guess you could say "The Domain Model is a set of Domain Objects ( classes ) that represents problem domain modeled in code". Wikipedia as good explanations of all the therms. – Iulian Margarintescu May 03 '11 at 13:00
  • I think the problem is that every CRUD I've seen has evolved into a full-fledged business application. In those cases the separation increasingly becomes a liability as more code gets jammed into "service" classes and all benefits of OOP get lost. **tl;dr:** in theory this answer is correct, but in practice every useful CRUD becomes a full blown app and then the anemic model becomes a pain in the ass. – Sled Oct 14 '11 at 16:58
2

The domain objects are seperated from the business logic of the software. This is an important idea of procedural programming.

However this pattern is considered to be a candidate for an anti-pattern by some developers which means that it might be a ineffective practice.

In fact you could consider disadvantages

  • your model is less expressive, getters and setters aren't really good to describe the model
  • code is harder to reuse, you get dublicated code among your transactional scripts
  • you have to use wrappers which hide the actual data structure (so maybe not really OOP)
  • there is always a global access to entities

I think the most interesting point to consider is that domain model's objects cannot assure their correctness at any time. Because their mutation takes place in seperated layers.

I worked on a CRUD application with zend framework too. The clear separation between logic and data is really great but when you progress you realize that the amount of layers and mappers gets bigger and bigger. Try to reuse your code as much as you can and avoid dublication.

DarkLeafyGreen
  • 69,338
  • 131
  • 383
  • 601
  • Your question clarifies really well the: "Why is anemic domain model an anti-pattern". But it doesn't answer another issue presented by my question: On a Table Data Gateway / Data Mapper Design Pattern - like the the one presented on the Zend Framework Quick Guide tutorial, are we also dealing with an Anti-Pattern case ? – MEM May 03 '11 at 11:41
  • 1
    There is no resource that defines this pattern as an anti-pattern, at least I couldn't find one. I pointed out that some developers see it as a candidate for an anti-pattern. So on the one hand you have the benifit of clear seperation and on the other hand the disadvanteges. You see there is a lot of "contra" which means it lis likley to be an anti-pattern – DarkLeafyGreen May 03 '11 at 11:46
  • "your model is less expressive" - when you are modeling a CRUD app there is nothing that the model needs to express beside get/set and maybe some validation. "code is harder to reuse" - again CRUD is generally simple, and with the right framework behind this is not an issue. "model's objects cannot assure their correctness" - If you expect this from your domain objects then you need to start designing them using DDD (grouping them into Aggregates that act as consistency boundaries, etc) and in this case having an anemic domain model IS and anti-patern. – Iulian Margarintescu May 03 '11 at 13:09