Decoupling into DAL and BLL - my concerns.

Question

Hi,

In many posts concerning this topic I come across very simple examples that do not answer my question.

Let's say a have a document table and user table. In DAL written in ADO.NET i have a method to retries all documents for some criteria. Now I the UI I have a case where I need to show this list along with the names of the creator.

Up to know I have it done with one method in DAL containig JOIN statement. However eveytime I have such a complex method i have to do custom mapping to some object that doesn't mark 1:1 to DB.

Should it be put into another layer ? If so then I will have to resing from join query for iteration through results and querying each document author. . . which doen't make sense... (performance)

what is the best approach for such scenarios ?

Answer 1

For your ui my suggestion is to have a dto (a viewmodel for those mvp/mvc people) hold the user's data and the corresponding list of documents.

Custom mapping will always be present so I suggest you take a look at Automapper here to ease those mapping pains.

Answer 2

I ran into the same thing in the past while creating my own custom data access layers. You want your objects to map one to one to your db, but many times you just need to write one off custom functions to retrieve inner joining data. I would not put these custom actions into their own layer.

At times, what I have done was created a general class that was responsible for retrieving data for grids, combo boxes, etc, that joined information from a number of tables. This class would return custom objects containing the retrieved results. I you are not satisfied with a tool that performs automatic custom mapping for you, I would suggest creating your own auto mapping class builder utility.

As long as you split your app into data access, business, and UI layers I think you are headed in the right direction.