POCO’s are allowed to have behaviour…

…in fact they probably should. I was recently told that logic shouldn’t be put into the domain because the domain objects are simple POCO’s. This seems to be a misunderstanding of the term.

POCO is derived from the term POJO, first defined by Martin Fowler et al. A POJO (Plain Old Java Object) is simply an object that has no dependency on an external framework, a backlash to EJB’s and heavy fraweworks that enforced inheritance.

POCO’s, like POJOs never precluded behaviour. In fact, POCO’s without behaviour are commonly referred to as “Anemic”, an anti pattern described by Fowler here.

In general, the more behavior you find in the services, the more likely you are to be robbing yourself of the benefits of a domain model. If all your logic is in services, you’ve robbed yourself blind.

This doesn’t mean Anemic Models are all bad, as Jimmy Bogard writes here: “Context is King” and sometimes a “Persistent Model” is sufficient to meet the systems needs.

So when thinking about modeling your domain, don’t simply disregard modeling it’s behaviour because they are only “simple POCO’s”, you might be robbing yourself blind.

One thought on “POCO’s are allowed to have behaviour…

  1. Some people can’t decouple behaviour from persistence; therefore they only think in terms of service-type classes being able to “do” stuff. This is not true; classes in your object model often need to “do” stuff that isnt necessarily related to how their state is managed.

    The OO 101-canonical “Car” example is a good one.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s