How to split a data layer and business object layer, what are the appropriate duties of each?

Question

If there was a line of business application layered like this, would this be an appropriate division of labor :

Data Access

• Invokes only stored procedures, maps properties of DTOs to a hash tablse which are used to populate ADO.NET command's parameter collections.

• Only assembly with reference to SqlDataClient.

• Significant logic dealing with what means blank, null, and empty in the mapping code, but other wise no validation or other domain specific logic.

So-Called Business Logic

• splits multiple result sets into individual DataTables, e.g.

  public void ReturnNthRecordSetFromStoredProcFoo()

• pass through to data access for datasets, e.g.

  public void ReturnDataSet(string name){ return (new PersonController).GetAnotherDataSet(name);}

• maps one row of a DataTable to one DTOs

• Significant logic dealing with what means blank, null, and empty in the mapping code.
• Holds transaction object, although it is used exclusively to wrap single stored procedure calls.
• Doesn't have a reference to SqlDataClient, so it can't use SqlDataReaders to fill DTOs
• No reference to System.Web.UI
• Authorization rules, but otherwise no domain specific logic.

UI

• 2 way data binding of DTOs to ASP.NET forms.
• Validation of properties of controls- generally no validation directly against DTOs
• "Collections" are navigated by binding DataSets to grids. In fact attempting to do anything with collections requires the UI to iterate over DataRows in DataTables and know what the appropriate column names are (which are generally only kind-of-similar to the DTOs)

So the question, finally-- with this application, should the Data Access Layer assume the the duties of the so-called business layer be merged? Isn't this already a two layer, (almost one!) application except for the inconvenience of an extra assembly?

Additional info: Ok, I already know that the application server will be one machine, probably forever, since it is an low-user-count intranet app. So I know not to design for physically separate application tiers. Also, it will probably only support one UI and be entirely scrapped if it ever need to support something other than ASP.NET-- another oft quoted reason for tiers/layers.

Answer 1

I would expect to see what you describe as your business layer as data layer type stuff. I'd hope that my data layer would shield me from having to worry about nulls and such things. I'd also hope that my business layer would contain business rules and concepts that are more abstract. For example if a "Group" is a collection of "User"s I'd like to see business type functions to manipulate those Users as part of a Group at a high level. For example maybe a function that would assign permissions to all the members of that group or allow the UI level to apply policies to those users as members of a group. I wouldn't hope to see functions that try to hide the fact that they all came from a database. I hope this is helpful.

Answer 2

Depending on your server load should determine the number of physical layers. The number of logical layers is really more of a personal choice.

In our organization we use the CSLA framework. It is a business object framework that strives to make rich, databound UIs simple to use and maintain, while giving flexibility in the data layer.

I wont go into too much depth here as it would be better for you to determine for yourself if the framework is worth it for you to use, but needless to say, it has its own SafeDataReader class which accounts for nulls, eliminating the need to use datasets.

Its "dataportal" (article is older but still relevant) allows you to easily move the data access to its own layer with very little effort, and no change of code.

DNRtv has a few video pod casts in which the designer of CSLA, Rockford Lhotka, shows the workings of the sample application. Part 1 and Part 2.

The shows are only an hour each and can probably help you decide if its the right thing for you to use.