Is this an anemic domain model?

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.

Consi开发者_运维技巧dering 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.

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.

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.