views:

42

answers:

1

I am going though this msdn article by noted DDD expert Udi Dahan, where he makes a great observation that he said took him years to realize; "Bringing all e-mail addresses into memory would probably get you locked up by the performance police. Even having the domain model call some service, which calls the database, to see if the e-mail address is there is unnecessary. A unique constraint in the database would suffice."

In a LOB presentation that captured some add or edit scenario, you wouldn't enable the Save type action until all edits were considered valid, so the first trade-off doing the above is that you need to enable Save and be prepared to notify the user if the uniqueness constraint is violated. But how best to do that, say with NHibernate?

I figure it needs to follow the lines of the pseudo-code below. Does anyone do something along these lines now?

Cheers,
Berryl

try {}
catch (GenericADOException)
{
    // "Abort due to constraint violation\r\ncolumn {0} is not unique", columnName)
    //(1) determine which db column violated uniqueness
    //(2) potentially map the column name to something in context to the user
    //(3) throw that can be translated into a BrokenRule for the UI presentation
    //(4) reset the nhibernate session
}
+3  A: 

The pessimistic approach is to check for unique-ness before saving; the optimistic approach is to attempt the save and handle the exception. The biggest problem with the optimistic approach is that you have to be able to parse the exception returned by the database to know that it's a specific unique constraint violation rather than the myriad of other things that can go wrong.

For this reason, it's much easier to check unique-ness before saving. It's a trivial database call to make this check: select 1 where email = '[email protected]'. It's also a better user experience to notify the user that the value is a duplicate (perhaps they already registered with the site?) before making them fill out the rest of the form and click save.

The unique constraint should definitely be in place, but the UI should check that the address is unique at the time it is entered on the form.

Jamie Ide
It drives me nuts to fill out a long registration form only to find out that demon$layer69 is already taken.
Jamie Ide
This implies doing that check in your Email property setter right before your property change, if not a dup, and add a BRoken rule if it is. Sweet
Berryl
So *you're* the one who has been taking my demon$layer69 nick :-)
Berryl