7

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?

1 Answer 1

5

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.

2
  • okay from what I can tell the Repository is an object that provides generic methods (getall, delete etc.) on a dataset, but it assume that the dataset is in a common format (e.g. .NET's DataContext) is that about right? The problem is that the format of the XML data is totally different from the the data in the database. Does that mean the Repository pattern won't work? Oct 17, 2012 at 22:12
  • A repository isn't exclusive to relational databases, it can be used to encapsulate access to XML data as well. It is more effective to consider a repository as encapsulating data access of any kind. Also, it isn't required that you implement all the CRUD methods on it, or that it emulates a collection - those characteristics have other benefits, but not as important as encapsulation itself.
    – eulerfx
    Oct 18, 2012 at 19:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.