I have a situation where my application allows user administration of various entities that have unique fields, such as Name. This is a web app and I am making use of the CslaDataSource to work with the object. Because of this approach, each object is instantiated as a stand-alone object and not a part of a parent collection.
In reviewing all of the previous posts that have touched on this, including http://forums.lhotka.net/forums/thread/4928.aspx and
http://forums.lhotka.net/forums/thread/7973.aspx, I've found that they all refer to checking if the parent collection contains an element sharing the value of the unique field. This is not possible here because we are in a multi-user environment and no parent collection is being used. Nonetheless, when a new customer is created, I need to ensure that the name is unique, for instance.
My initial thought is to execute a Command object when an attempt is made to save the object (either Insert or Update) that will perform the necessary logic to validate that the name is unique (there are some boundary issues in place, as in "unique within...", that are not emulated in our object model but that'll just over-complicate the discussion). If the Command object returns true, then we execute the Insert or Update as appropriate; otherwise, we return an error message to the user.
However, this now requires two round-trips to the database each time we want to save an object. Would it be better to simply perform the uniqueness check in our stored procedure and return an error code if the name is not unique? I hesitate to use error codes from sprocs because there's no direct correlation and you have to get into rules defining what an error code means, etc.
So, my question is how to perform a uniqueness test that MUST be performed on the database before an object can be inserted/updated?
Any suggestions?
I think in the case of the stateless web app, the Command object is less useful for this scenario. To me, a Command object comes in handy in a WinForms app when you want to provide the user with instant feedback the moment they enter data into the unique field. Unless you use Ajax (where you could fire off a Command object when the Textbox lost focus), I think the simplest approach would be to simply do that check by the database when the BO is committed.
Of course, the unfortunate thing here is that we're altering the design of the middle tier to accommodate the needs of the UI. Ideally the middle tier would be UI-agnostic, not having these types of constraints (i..e you would still implement the Command object). But if you're not having to service a WinForms UI, I would tend to keep it simple. You can always refactor a Command object back into the middle tier in the future if you need to.
I have a large Web app in production.
I use broken rules to check these kinds of things. That way the BO does not make the trip to the DataPortal until it is valid. Recognizing that 2 users could simultaneously add the same name means I still have the constraint in the DB as a backup. In my Broken Rules I call a CommandObject to give me the T/F response on uniqueness. This makes Validation a bit more expensive - but I think it is worth it.
Joe
Copyright (c) Marimer LLC