Should DAL check for existence of object before creating or updating

Question

I am working with an N-tier application, and I'm updating the Data Access Layer (DAL) to use a new ORM. As I'm updating the DAL I'm finding some issues with how we save objects to the database.

One question I have is should the DAL have a simple SaveObject(objectToSave) method that checks for it's existence in the database and then either updates or saves the object? Or should the Business Logic Layer figure that out, and the DAL only have CreateObject(objectToCreate), UpdateObject(objectToUpdate), and ObjectExists(objectToLookFor) methods?

Answer 1

That's a classic architectural decision. You'll want to look at the pros & cons of each approach, and make the decision that's best for your system's consumers.

The benefit of the Save/Upsert approach is that it simplifies the API. Many systems do this, including Salesforce.com.

But, if the consumer knows (to the extent possible) that a record is brand new, it is more efficient to do a Create/Insert without first applying a lock and checking for existence.

(Although your database might be super optimized for Save/Upsert - you'll want to consider that too.)

Lastly, you'll want to think about the concurrency behavior you're exposing to the consumer. For example, if the consumer believes it's adding a brand new record, but in reality another user has slipped in ahead and created the record, is it ok to quietly update the record? Or is it better to return a hard error ("record already exists")?

Answer 2

Data constraints such as uniqueness can only be enforced by the database server itself. It alone implements the locks and other ACID properties required to address this issue, which incidentially is a very common concurrency control problem.

In order to make this work, you can either deal with it in stored procedures, or if you are lucky you can configure/program your Data Access Layer so that it will do it for you. If the DAL does it, it will still need to create a database transaction, but it can take care of the implementation details.

The business layer can't do it because it does not know how to construct the right kind of transaction to prevent concurrent users from interfering with your uniqueness rule. You can still do a preliminary check, but you also need to handle the sort of exception that could be raised if the object gets inserted by someone else in the narrow time between your check and insert.