Data Access Layer or having object with CRUD methods?

Question

I used to have a Data Access Layer that take the object by parameter and handle with abstraction the type of persistence required. At my new job, the architect is thinking to implement CRUD operation (load..save..delete..update) into all model object. Those method would have an object by parameter that will handle the saving of the object. Exemple : load(IPersistence persistence). I have some doubt about the extensibility and that each model object would have to implement all load,save,delete,update method.

What is the best approach?

Answer 1

I guess that's the eternal question and both approaches do have their pros and cons and lots of followers who swear by them.

The repository approach that you seem to favor (having a Repository/Gateway whatever you call it) to handle the CRUD operations makes your actual business classes smaller and leaner, since they probably only contain data and possibly validation / business rules.

In this case, you'd implement the CRUD operations once - but most likely once for each type of object you're dealing with.

On the other hand, the smart business object approach might argue that CRUD operation on a given entity are specific to that entity anyway, so the code to select, update, delete such an entity is always going to be specific, so it might as well reside inside that object itself.

In this case, you'd implement the CRUD operations once for each object class - I don't see any big disadvantage over the repository approach in this case, really.

I personally lean towards the repository approach myself today, but I do also see benefits in the "smart business object" approach - both are valid, and I guess you'll just have to either convince your new architect of your position, or get to terms with a different approach.

Marc

Answer 2

DAL all the way.

You want to be able to isolate your transactions so the objects shouldn't be aware of their persistence. Otherwise the code can tend to an unmaintainable nightmare where objects can activate database round trips and it is difficult to roll a number of transactions into one atomic action.

I found out this the hard way. :)