Plain Old CLR / C# Object
Crap, time can go by so fast. On Monday a tweet by Ralf Westphal caught my attention and I felt the need to comment. It started as a series of Twitter replies, but to be honest Twitter isn’t suited or made for those kind of discussions. So I started to write this post in order to explain why I disagree with Ralf (or at least don’t get the intended message of his tweet). Yeah a short look into the calendar indicates that I’m a little late, but I thought better late than ditch the post and forget about it.
What got me baffled
In his tweet he basically states (my translation from German to English) that
“If a domain model consists only of POCOs it should be called data model”
My first thought was a) does he mean anemic domain models and b) what has POCO to do with that? As I found out he didn’t mean anemic domain models. So let’s take a look at the POCO aspect.
POCO / POJO / PONO / POwhateverO
The term exists in several variations and different programming languages. For the sake of simplicity I’m going to use POCO for the rest of the post since I’m a .NET guy, but same applies of course to all other versions. The English Wikipedia side defines the term “Plain Old CLR Object” as the following:
”… The term is used to contrast a simple object with one that is designed to be used with a complicated, special object frameworks such as an ORM component. Another way to put it is that POCO’s are objects unencumbered with inheritance or attributes needed for specific frameworks …”
To me personally, POCO is just a simple, but very important principle or guideline. POCO for me means, that you should strive to limit the contact area of your own code and the code of third party frameworks as much as possible. This includes staying away from third-party frameworks with heavy attribute usage and / or inheritance requirements. Why should you do this? 2 reasons seem to be important to me:
- Orthogonality. Two parts of a system, like features, components, classes, whatever are called orthogonal when changes in one don’t affect the other. Following a POCO approach in a solution can greatly support orthogonality in my personal experience. It helps you to design and build solutions that are easy to change and very adaptable to new requirements or frameworks (Ever tried to migrate a Microsoft CAB based solution?). Which leads to the second IMHO very important aspect:
- Reversibility. In the end of the day we’re all human. Sometimes we design the wrong way, sometimes the framework doesn’t work as expected, sometimes a particular framework isn’t exactly the right one any more when requirements change drastically. All those things happen. All those things can can come up in any project. POCO can help a lot in those situations, because it limits the impact of external frameworks or components to your code.
POCO mostly comes up in the context of an ORM solution. However, the concept of POCO is not directly bound to persistence or even domain models. Which leads me back to the entry of the post and Ralfs tweet. What is the main distinction between a domain model and something we might call a data model? In my opinion this is BEHAVIOR. The term POCO itself has nothing to do with behavior itself (at least from my perspective). Totally different aspects IMHO. So why should a model consisting of POCOs be called data model?
Am I fighting on lost ground here, missing something or confusing something?
8 Responses Leave a comment
I don´t understand why we should disagree. You´re saying: “The term POCO itself has nothing to do with behavior itself (at least from my perspective).”
Right! POCOs do not contain behaviour. They´re just data. (Or maybe just trivial behaviour. INotifyPropertyChanged to me is trivial.) Maybe complicated data. In my view POCO classes can inherit from each other and can aggregate others. With POCOs we can build object graphs.
But that´s it. POCOs are not more. But still they are often called “domain models”.
But what makes them so “domain model” like? Because there are classes called Customer or Order? Sure, that´s terms from a problem domain. But then you can´t really avoid using them. So I don´t think they have much distinguishing quality. But “domain model” needs to be distinguished from “data model”. Otherwise the term “domain model” would not make much sense.
That´s why I say: Objectgraphs consisting of POCOs are not “domain models” but just “data models”. “Domain models” are different from “data models” because (!) are about behaviour. So if POCOs are not about behaviour, they can´t define “domain model”. Ergo: they are just “data models”.
-Ralf
agreed
@ralf All your assumptions are based on the idea that POCO is tightly coupled to domain (or data) models. In my opinion that’s simply not the case. POCO is a principle which can be applied to all building blocks of a solution. Not just the model.
Besides, when I say “POCO has nothing to do with behavior” that doesn’t rule out that you can have a full blown domain model WITH behavior AND following a the POCO. What I wanted to say is that in my opinion POCO and the richness /behavior of a domain model are orthogonal concepts. That’s why I disagree with your statement.
-Bjoern
From my perspective it’s a problem of definition – or let’s better put is as perception – of the term POCO.
While @ralf perceives a POCO to be a “similar” concept to VO’s or DTO’s, @bjoern’s perspective considers a POCO to be an object not being enriched or dependent on any other component or framework. I personally favor to understand a POCO the way Bjoern mentions it in this article.
Although lot of developers use POCO as a synonym for VO or DTO, IMHO it’s not what a POCO actually stands for. The term is an artifact of the ORM problem / design model. If an ORM supports POCO, it usually depicts that the ORM framework is capable to inspect & persist any given CLR object without modifications to the object itself. Given this background, orthogonality is a key aspect of POCO’s.
I tend to get the point of Ralf. He’s just arguing the fact that the’re people out there creating DTO’s or “Entities” with EF or whatever and label those as domain model. This more likely is the viewpoint of an anemic domain model, as far as I understood Ralfs statements.
@Ilker Very thoughtful commentary. I think we’re on the same line with this.
Funny thing is, I totally agree with @ralf assertion that a lot of the domain models out there are just plain anemic data models and shouldn’t be called a domain model at all. This just hasn’t anything todo with the POCO principle IMHO.
-Bjoern
I think we should pay some credit to the history of the word POCO here. Its origins are on the Java side of things: The term “Plain Old Java Object” was coined to express that an object is not an EJB. That did not mean it cannot have any behaviour, it just meant it does not inherit from any EJB framework classes or carry EJB annotations.
I would still stick with this meaning – whether our POXO runs on the JRE, the CLR or wherever else – and thus agree with Björn: a POCO is one thing, objects without behaviour another.
I would agree to Bjoern’s statements. POCO is defining a *technical* term, a missing dependency to specific frameworks. It doesn’t make any *conceptual* statement if classes have only state or contain behavior as well (and thus are forming data or domain models). So a (technical) POCO can be (conceptual) anything…
Terms like POCO, VO, BE, domain and data models are often misused, so please don’t promote the confusion.
~ Matthias
That’s a very interesting discussion. While Martin Fowler makes a very clear statement about DTOs (http://martinfowler.com/eaaCatalog/dataTransferObject.html), I was asking myself what’s the difference between VOs, BOs and POCOs. I searched the internet and found – this. Obviously there are different opinions.