Interfaces: Doing the DAO

Often there is the question as to where save() should be broken out into insert() and update(). Most commonly, you insert if the Object.ID is 0 and update if it is not, but sometimes it is nice for a DAO to be able to test an object for uniqueness in some other manner (email address or first name, last name and address1) and to follow certain business rules depending upon whether the uniqueness test is passed (check out Steve Bryants seriously underused DataMgr for an example of this).

All things considered, I’m going to delegate the decision of whether to insert or update down to the DAO and it can decide whether to call its private Insert() or Update() method for each record to be saved.

There would be a real argument to adding a validate method to the DAO that would specifically validate the passed data against the db introspected metadata to make sure you’re not trying to save a float in an int or 100 characters in a varchar(15). For now, I’m not going to implement that as it is doing at runtime what could quite easily be done at generation time by writing a tool to ensure that every custom data type is validated in a manner that is consistent with its underlying persistence requirements.