Trying to avoid validating entities in service that were validated in the UI.

Aug 13, 2011 at 3:29 PM

Hi, I have been using your framework in my Domain Driven Design framework for some time and we are starting some new projects and I would like to get your opinion on an idea I have.

My aggregate root entity base class has the ValidationCatalog.Validate() logic so that developers will:

entity.Validate(); // Throws an InvalidDomainEntity exception with appropriate information if invalid.

if (entity.IsValid)… // returns bool, no exceptions

Our domain services always validate the entity being passed in for inserts or updates before the service passes the entity to the appropriate repository. The problem is normally the entity is valid as the presentation layer might be using an IDataErrorInfo interface on the view model that ties into the SpecExpress validation built into the entity (model).

Unfortunately, the domain service can’t assume that an entity is valid. Because some of the entities have very large object graphs, it can be an expensive call to revalidate a valid entity.

If the entity (aggregate root) had a switch (entity.IsValidated) which could indicate that the catalog validate() was run and if successful, the entity is in a state of validity. I would then have to put a mechanism in place to turn that switch off if any object in the graph had a property that was changed. Or it would have to test the property for validation and switch the IsValidated property accordingly.

Implementing an INotifyPropertyChanged contract or similar in my entities sounds like a presentation layer concern and would be very heavy (lots of code for every property) and dirty my POCO entities.

I could use PostSharp to emit this logic into the IL and it would appear that I still had POCOs but it still seems like the wrong concern.

In your opinion, am I over architecting this problem? Can you think of a better pattern or solution? Thanks!

Coordinator
Aug 13, 2011 at 11:37 PM

It sounds like you only want to validate your object graph if it's dirty. Do you use an ORM? NHibernate offers some "dirty checking". I'm not sure about Entity Framework.

Out of curiosity, how expensive is it to validate an entity / object graph? Is it because of the number of objects, the complexity, or that you have to make database/repository calls to validate the entity?

Thanks,

Alan

Aug 14, 2011 at 3:20 AM

We are using NHibernate, we validate the entity with entity.Validate() before we pass it to the repository.  We are not using lazy loading or a session as we will convert to a DTO and send across the wire with WCF depending on what is needed.  The domain service does not know if it is in process with the UI or if it is going through a thin WCF layer. On the other side, the DTO is converted back to an entity.

I have seen it take over a second to validate an entity, mainly because of the number of objects.  All specification info is in the class and its not really that complicated.  I'm not complaining so much about the second it takes to validate, only that the vast majority of the time it is re-validating a valid object graph.

You are correct, I only want to validate if it is dirty and I am trying to figure out if building that logic into the aggregate root base class is worth it.

Thanks, Bill