Menu
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?
531
Data-Access Layer (DAL) Data-Access Layer is a layer in an application that provides easy and simplified access to data stored in persistent storage, such as an entity-relational database or any database for that matter. It is layer that exists between the Business Logic Layer (BLL) and the storage layer.
CRUD refers to the four basic operations a software application should be able to perform – Create, Read, Update, and Delete. In such apps, users must be able to create data, have access to the data in the UI by reading the data, update or edit the data, and delete the data.
CRUD is an acronym that comes from the world of computer programming and refers to the four functions that are considered necessary to implement a persistent storage application: create, read, update and delete.
The data layer manages the physical storage and retrieval of data. The business layer maintains business rules and logic. The presentation layer houses the user interface and related presentation code.
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
183
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. :)
4
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
