Here is how I see the main differences between the DAL and the BLL:

  • The DAL directly query the database.
  • The DAL doesn't create new information. It may execute complex sql requests, joining several tables, but the result of such a request never gives any information that wasn't already in the database.
  • The BLL applies a business logic on the DAL's informations to create new informations.

Now, I wonder what datatypes these layers' functions are supposed to return. For the moment, all my DAL's function return DataTable. But my BLL's functions return some class or list of class that I created.

For example:

  • dal.getAllPortfolios() returns a DataTable (I'm working with Visual Studio), result of a join on several tables.
  • bll.getAllPortfolios() calls dal.getAllPortfolios, but return a List of Portfolio. With my public Portfolio class being in the BLL's namespace.

Sometimes, the BLL function doesn't really apply any "business logic" but only map the DataTable from de DAL into a BLL's class.

I wonder if this is ok. Maybe all the mapping work should be done by the DAL? If this is the case, where to put my personal mapping classes? In the BLL or DAL namespace (those classes being required in layers above the BLL)?


I would say that's perfectly acceptable - even desirable. The DAL should only be Data Access - that's why it's the Data Access Layer. The BL, on the other hand, should never interact directly with the database, but should take the data retrieved from the DAL and put it in a more consumer- or developer-friendly format to be leveraged in your code.

By maintaining this separation of concerns, if you ever changed databases (either database structure, or database type, or the physical server itself) you only need to make changes in the DAL. Generally speaking, the DAL will only have basic methods for executing stored procedures, queries, etc., and returning single values or data tables/data sets. It sends those back to the BLL, which then creates the necessary objects to be consumed. If you want an easy (if overly-simplified) way to visualize it, a Google Search popped up this image: enter image description here

| improve this answer | |
  • Ok, I was a bit confused due to the general usage of Linq2sql, which automatically maps a class for each table in the database, and allow a direct mapping of the result from Linq queries into some personalized class. As a result, it seems to me that projects using this technology have a DAL whose functions all return "personalized" classes instead of DataTable/DataSet. I'm not using Linq2sql for several reasons. In contrast, my DAL creates SqlCommand objects with pure old SQL queries, and only return DataTable objects, which are not mapped into any other class before reaching the BLL... – Yugo Amaryl Jan 3 '14 at 17:58
  • LINQ2SQL is getting pretty common these days as a way of bypassing the DAL, however having the separate DAL and BL layers is still a valid model to use, at least in my opinion. Though you might look into replacing the inline SQL with Stored Procedure calls (it will make your DAL much more manageable). – Locke Jan 3 '14 at 18:05
  • Well, I saw some solution having DAL and BLL projects, with all the same structure, but simply replacing the SQL queries of the DAL project with Linq. So you would say it's not a DAL anymore? About the stored procedures, yes, you mean using Transact-SQL... I thought about it. I'm used to Oracle PL/SQL and thought I didn't have time right now to explore the difference between the two. I must admit having long strings with parameters as queries is not very nice, but it does the job for the moment. – Yugo Amaryl Jan 3 '14 at 18:12
  • Using Linq in place of SQL in the DAL is fine - it's still a Data Access Layer. The basic structure and separation of concerns is the same. – Locke Jan 3 '14 at 18:19

There is no need to abstract getting data from one layer to another unless 1 or more transformations are going to occur to put it in a format the consumer expects.

Mapping of data tables to collections of objects before returning from the 'data access' is more prudent than having a separate class / function to do so unless you have consumers expecting different return types

| improve this answer | |
  • +1 I would do the mapping in the data layer. Does your business layer really need to know about columns, child relations, parent relations, PK. That's what a data table has. I guess it's debatable where this "transformation" layer should live. I'd bury it in the DAL and return more consumable objects that are easier to work with. – Jon Raynor Jan 3 '14 at 22:05
  • Jon Raynor: and what about having for example a function DataTable DAL.getPortfolio(int portfolioId), then a BLL.Portfolio BLL.getPortfolio(int portfolioId) calling the DAL function, and then other functions BLL.applySomeLogic(BLL.Portfolio parameter)? – Yugo Amaryl Jan 4 '14 at 17:21
  • I mean: so the mapping is done in the BLL, but the BLL functions that really apply a complex business logic can use those "more consumable objects"... – Yugo Amaryl Jan 4 '14 at 17:28
  • Yugo, why do you need a specific BLL function to perform the mapping independent of the DAL? Are any other aspects of the architecture going to call the DAL and use a DataTable? – Kevin Jan 5 '14 at 15:43
  • Kevin: no. So you would vote for doing the mapping in the DAL... – Yugo Amaryl Jan 19 '14 at 14:34


So, I left my architecture how it was described in my first message, with my DAL returning DataTable objects. I was criticized for that choice. The argument was that, if different persons work on the DAL and the BLL, the one working on the BLL is going to need more documentation to use the DataTable objects. This person doesn't know the name of the columns in the DataTable, and maybe not even how to extract informations from a DataTable.

| improve this answer | |
  • That sounds like pretty good feedback, and I wouldn't take it as harsh criticism. What I would take away from it is a different approach in creating an API. By using a type instead of a data table you can represent the domain object, rather than a less expressive data entity. – Kevin Jan 19 '14 at 21:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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