5

By Smart object I consider any Domain object that knows its original property value if property is altered. Smart objects usually have a base class and implement properties by using GetPropertyValue/SetPropertyValue methods. On the other hand POCO objects would commonly have no base class and implement simple properties.

public class SmartObject : BaseDomainObject
{
    public int id
    {
         get { return (int)this.GetPropertyValue("Id"); }
         set { this.SetPropertyValue("Id", value); }
    }
}

public class POCO
{
    public int id { get; set; }
}

I like Smart object because it does a lot of hard work for me. I can easily add all those useful features to BaseDomainObject and have them in all my derived Domain classes:

  • common properties (like Id, Status...)
  • object state tracking (new, modified, unchanged)
  • all properties raise events on property changes (implementation of INotifyProperyChanged)
  • derived classes can be automatically be serializable (although I rarely find this useful)
  • I can have all this other behavior that can be useful - Clone/Sync/ IsPropertyDirty...

On the other hand POCO's are super simple and have no dependency to any base class.

Nowadays I here a lot of POCO praising because:

  1. it can be sent over the wire (usually to web browser as JSON)
  2. it is pure

On the other hand I think that reasons above are fallacy because:

  1. DTO's are for wire transfer and not domain objects. Behavior encapsulating data if lost when domain object is serialized to JSON.
  2. this chase for purity seams like chase for even more anemic domain model which doesn't have logic nor anything smart attached to it.

With all this sad, I still like that POCO and it bugs me. What is your opinion?

Vukoje
  • 500
  • 4
  • 9
  • 2
    If you are striving for a rich domain model, do not pollute it with technical infrastructure concerns. All of the things you mentioned - state tracking, property changed events, serialization - none of these things have anything to do with the domain. They do nothing to encode the complexity of the business domain into the model. – MattDavey Jul 26 '13 at 10:23
  • On the other hand, a POCO also does nothing to encode the domain complexity into the model. So by DDD standards, both approaches are very poor. – MattDavey Jul 26 '13 at 10:39
  • 1
    @MattDavey I agree with your first comment but I'm not sure about the latter. POCO != anemic, if that's what you're implying. Plain Old Object Oriented *does* include behavior, and if applicable, Domain behavior, in addition to data. – guillaume31 Jul 26 '13 at 11:21
  • @guillaume31 you are correct. It seems lately that POCO has become synonymous with an object which contains only getters/setters (leading to confusion with DTO objects). We should remember the true meaning of POCO, which you explained in the last sentence of your question. – MattDavey Jul 26 '13 at 11:30

2 Answers2

4
  • common properties (like Id, Status...)

I wouldn't consider an object to be non-POCO if it just inherits, say, an Entity base class that defines an Id property. An entity by definition has an identity, that doesn't break SRP nor does it alter the "purity" of your object by importing third party behavior.

Status is more debatable, depending on what you mean by that it might indeed introduce additional responsibilities in your object that makes it non-POCO.

Most other properties you mention I think should be handled by external objects, not the domain object itself.

  • object state tracking (new, modified, unchanged)

It would be better to have change tracking-specialized proxies of your domain objects handle this (this is typically what ORMs do).

  • all properties raise events on property changes (implementation of INotifyProperyChanged)

I see that as mostly UI-related stuff that goes into your presentation objects but not your domain objects. You'll probably not want every property in your entities to be observable - to signal changes in an Aggregate, use Domain Events instead.

  • I can have all this other behavior that can be useful - Clone/Sync/ IsPropertyDirty...

Clone can typically be a basic behavior of Value Objects without them being considered non-POCOs. Cloning entities seems less useful to me except your occasional domain specific need. Sync/IsPropertyDirty again seems more like versioning / change tracking and should be delegated to a specialized object.

this chase for purity seams like chase for even more anemic domain model which doesn't have logic nor anything smart attached to it.

The problem here is all about "attached". It's not that SRP-compliant objects aren't smart, rather that they don't include anything smart that is not their natural responsibility. Similarly, POCO's aren't dumb, they are just objects that weren't transplanted with behavior from external sources (3d party libraries, framework extenstions...)

guillaume31
  • 13,738
  • 1
  • 32
  • 51
  • 1
    +1 for "You'll probably not want every property in your entities to be observable - to signal changes in an Aggregate, use Domain Events instead." – MattDavey Jul 26 '13 at 10:20
  • I especially like how term **"attached"** revealed problem itself. – Vukoje Jul 26 '13 at 20:08
  • Also I think that with MSIL generation, things like cloning can be easily delegated to other components without requiring to alter the way data is stored on object. E.g.[EmitMapper](http://emitmapper.codeplex.com/). I also agree that state tracking inside object tends to create troubles but I also don't like complete dependency on ORM state tracking as it usually requires some extreme techniques. But fortunately Id property that is 0 for new objects goes a log way. – Vukoje Jul 26 '13 at 20:14
1

I would stick with POCO inside model because those "smart objects" introduce so much complexity. Model should be simple as it gets, carrying only business logic, not polluted with features that could be useful. Especially technical one...

gseric
  • 649
  • 4
  • 11