Take this simple, common scenario in an mvc app:
When a user registers the username needs to be unique.
Now I’ve read lot about project structure, domain-driven design, validation, mvc etc and I’m happy about my logical layers: Domain (Model, Core), Domain Services, Controllers and Views. I can ensure e.g. the username is less than 10 characters by adding a validation attribute to my property. Failures will bubble up back through the service layer into the controller and out into the view.
But for this simple scenario I am stuck as to the best solution for the call stack – and have that tested well, since this validation needs to call the db to check all other usernames.
For me, this is still a validation concern of the User model. I would really like to be able to create a custom validation attribute, so that when this property is set, persistence is checked to ensure uniqueness.
Woah there! A domain object calling the db directly?? I’m not sure its a bad thing. I can have castle inject IRespositories into the Domain, right, so no tight coupling and after all its the Domain that defines the data interfaces.
Does anyone have any experience/ opinions on this?
In the end I’ve stuck to my gut feeling that this type of behaviour should be handled in the Domain, and it seems I am not alone.
The recent builds of S#arp Architecture have included a new Class Validation attribute HasUniqueDomainSignature, used in conjunction with Property attribute DomainSignature. When calling IsValid on NHibernate.Vaidator, the Common Service Locator is used to locate the current NHibernate session and persistence is referenced.
Here’s a discussion on it.