Database – Architecting Model and Data Access Layer Objects for Websites

data structuresdatabasemodelmvc

I've been tasked with designing Data layer for a website at work, and I am very interested in architecture of code for the best flexibility, maintainability and readability.

I am generally acutely aware of the value in completely separating out my actual Models from the Data Access layer, so that the Models are completely naive when it comes to Data Access. And in this case it's particularly useful to do this as the Models may be built from the Database or may be built from a Soap web service.

So it seems to me to make sense to have Factories in my data access layer which create Model objects. So here's what I have so far (in my made-up pseudocode):

class DataAccess.ProductsFromXml extends DataAccess.ProductFactory {}
class DataAccess.ProductsFromDatabase extends DataAccess.ProductFactory {}

These then get used in the controller in a fashion similar to the following:

var xmlProductCreator = DataAccess.ProductsFromXml(xmlDataProvider);
var databaseProductCreator = DataAccess.ProductsFromXml(xmlDataProvider);

// Returns array of Product model objects
var XmlProducts = databaseProductCreator.Products();
// Returns array of Product model objects
var DbProducts = xmlProductCreator.Products();

So my question is, is this a good structure for my Data Access layer? Is it a good idea to use a Factory for building my Model objects from the data? Do you think I've misunderstood something? And are there any general patterns I should read up on for how to write my data access objects to create my Model objects?

Best Answer

I am generally acutely aware of the value in completely separating out my actual Models from the Data Access layer, so that the Models are completely naive when it comes to Data Access.

This is referred to as persistence ignorance. Another concept you may wish to introduce in your data access layer is the repository. The central function of a repository is to encapsulate data access.

In an MVC architecture, the controller would reference the repository to get access to data. The specific details of data formatting should be hidden by the repository, that way your controller remains persistence ignorant as well. Repositories however are sometimes misapplied when too much abstraction is attempted. Don't try to make repositories overly generic and capable of handling any type of data access scenario because you will most likely fail and end up with lots of needless abstractions that complicate far more than they simplify.

Related Topic