Business Objects within a Data Access Layer

Question

So I've been creating a data access layer via TDD and have approached somewhat of a concern. I'd rather not start down the wrong path, so I figured I'd ask you guys to see if my thoughts were in line with a clean architecture.

The methods within my Data Access Layer (DAL for short), are pretty simple. They are in line with the stored procedures in the database (no other way to call into it to keep things clean), and they contain those same parameters that the procedures do. They then just connect to the database, and return the query result. Here's one example:

public int DeleteRecord(int recordId)
{
    recordId.RequireThat("recordId").NotZeroOrLess();

    List<SqlParameter> parameters = new List<SqlParameter>();
    parameters.Add(new SqlParameter { ParameterName = "@RecordId", SqlDbType = SqlDbType.Int, Direction = ParameterDirection.Input, Value = recordId});

    return this.ExecuteNonQuery("DeleteRecord", parameters.ToArray());
}

This works perfectly for this type of method because I am not doing anything meaningful with the result set. I just want to make sure the command worked, so I will return the result of the non-query, which is just the rows affected, and I can verify the logic using that number.

However, say in another DAL method, I want to load a record. My load procedure is going to be executing selects against a bunch of tables and returning a DataSet, but I am battling with whether my DAL should create the Business Objects within the method using the DataSet, or if my Business Objects themselves should just have a Load() method that gets the DataSet from the DAL, and then basically fills itself in.

Doing it through the DAL would result in less logic in the Business Objects (even though this is just select logic, it's still logic), but would crowd the DAL a little bit and make it feel like it really is doing something that it shouldn't be doing.

What do you guys think?

Answer 1

Your DAL should return your data objects

Ideally your DAL should be a "black box" object, that your application code can use to ask for a data object or manipulate existing data objects. Sometimes there is another layer put between the DAL and the application code called the Repository, which further separates the two layers, although this is not always needed.

In addition, you usually do not want your business objects being able to create themselves. This can cause security holes where someone can use your library, and create a new instance of your object by calling .Load(someId) on it, and it merges together two layers that should be completely separate.

I also don't recommend providing a.Load(DataSet ds) method because if the data set definition changes, you'll have to hunt down the data objects which use that data set and change them. It's easier to keep all your data access code in one place, so if you change the data access query, you should only have to change your DAL layer.

Answer 2

My method, even prior to LINQ-To-SQL and Entity Framework, was to have an interface and abstract class library that provided a "written contract" for communication between different layers of the app. This is sometimes called an ontology, a definition for a work domain. Anything that passed between layers used this 'contract'.

I don't like the idea of passing raw Dataset objects from the data layer to the business layer. I've seen this result in a number of problems, especially when integrating legacy data sources. It can also make it very difficult for new people coming into a project to understand where data is coming from. Lastly, it requires your business layer to be in the business of handling data directly from the DB, which can lead to complications down the road.

The example code you had looks similar to code I had prior to LINQ. I had a common DB function class that I used inside my DAL objects. The DAL classes would read the data and fit it into the 'contract' objects. Scalar results, like your delete example, would return a value, usually a boolean.

Answer 3

Your DAL should return a Dataset. That Dataset returned should be the buisness object, there shouldn't be anything you need to do to it other than check that that it has the expected data. If you need to do more with it then you are either trying to do too much in a single stored procedure or not returning the data properly in the stored procedure.

Answer 4

I'd recommend your business objects have a constructor to populate themselves from a result set. This removes the coupling between your DAL and the business layer. If you want to completely isolate the two, create a simple map of column name => value pairs from your result set and pass that to the constructor.