Question

How do you apply validation in an MVP/domain environment ?

Let me clearify with an example:

Domain entity:

class Customer
{
  string Name;
  etc.
}

MVP-model

class CustomerModel
{
   string Name;
   etc.
}

I want to apply validation on my domain entities but the MVP model has it’s own model/class
apart from the domain entity, does that mean I have to copy the validation code
to also work on the MVP-model?

One solution I came up with is to drop the MVP-model and use the domain entity as MVP-Model,
but I don’t want to set data to the entities that isn’t validated yet.
And second problem that rises is that if the entity has notify-events,
other parts of the application will be affected with faulty data.

A third thing with that approach is if the user edits some data and then cancels the edit, how do I revert to the old values ? (The entity might not come from a DB so reloading the entity is’t possible in all cases).

Another solution is to make some sort of copy/clone of the entity in question and use the copy as MVP-model, but then it might get troublesome if the entity has a large object graph.

Anyone has some tips about these problems?

Answer 1

Constraining something like the name of a person probably does not rightfully belong in the domain model, unless in the client’s company there is actually a rule that they don’t do business with customers whose names exceed 96 characters.

String length and the like are not concerns of the domain — two different applications employing the same model could have different requirements, depending on the UI, persistence constraints, and use cases.

On the one hand, you want to be sure that your model of a person is complete and accurate, but consider the “real world” person you are modeling. There are no rules about length and no logical corollary to “oops, there was a problem trying to give this person a name.” A person just has a name, so I’d argue that it is the responsibility of the presenter to validate what the user enters before populating the domain model, because the format of the data is a concern of the application moreso than the domain.

Furthermore, as Udi Dahan explains in his article, Employing the Domain Model Pattern, we use the domain model pattern to encapsulate rules that are subject to change. That a person should not a have a null name is not a requirement that is likely ever to change.

I might consider using Debug.Assert() in the domain entity just for an added layer of protection through integration and/or manual testing, if I was really concerned about a null name sneaking in, but something like length, again, doesn’t belong there.

Don’t use your domain entities directly — keep that presentation layer; you’re going to need it. You laid out three very real problems with using entities directly (I think Udi Dahan’s article touches on this as well).

Your domain model should not acquiesce to the needs of the application, and soon enough your UI is going to need an event or collection filter that you’re just going to have to stick into that entity. Let the presentation layer serve as the adapter instead and each layer will be able to maintain its integrity.

Let me be clear that the domain model does not have to be devoid of validation, but the validation that it contains should be domain-specific. For example, when attempting to give someone a pay raise, there may be a requirement that no raise can be awarded within 6 months of the last one so you’d need to validate the effective date of the raise. This is a business rule, is subject to change, and absolutely belongs in the domain model.