Thank you for your tweet reply and kind offer of the updated SM source-code, either option is much appreciated so which ever suits you best (my email above).

I’m currently trying to create named singleton instances for multiple configurations in a multi-tenant architecture, returning an instance based on the current configuration (indicated via HTTPContext) and your pattern looked like an interesting opener to solving it neatly in SM 2.6+.

Thanks again for the kind offer of code

Ian

Terms like POCO, VO, BE, domain and data models are often misused, so please don’t promote the confusion.

~ Matthias

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

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.

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

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