DAL and BLL in .NET

Question

There is this DAL/BLL design suggestion by Microsoft for ASP.NET (2.0) apps. I know some of the alternatives and I've read related questions here on SO. However I wonder if this proposed solution is worth implementing nowadays, is there a specific downside you know of?

I want to develop DAL/BLL components for company-internal use, to access customer and employee data, etc from various applications and scripts. However before I start building that stuff, I want to be sure that this solution is 'good'. As example, the BLL passes datatables instead of encapsulating anything, you don't have isolated business objects that contain logic. It's basically only a dumb layer that eases the CRUD operations a bit and allows databinding for controls.

Could someone, who has experience in this field, point me out the pro's and con's of this approach?

Answer 1

pros:
- simple approach and some of the data mapping is done for you with the datatable's.
- offers some conveniences for firing Select, Add, Update and Delete queries.
- might be suitable for very simple design with few tables.
- suitable for non-self-referencing ER degigns or ER's with few lookup tables and simple/few joins
- suitable where simple data store is required. ie. where complex OO ideas should be applied to the "business objects" this pattern would make things more difficult.

cons:
- large OO models will struggle in this pattern
- complex ER designs with many tables, complex relationships or OO object requirements will not fit this pattern. the datatables dont provide much assistance for in-code object querying like LINQ.
- most queries need to be written by hand in SQL (this includes joins). yes, you can use the query designer, but this dont help much.
- there is a lot of code duplication in this approach. as in you will write lots of CRUD methods in your BLL classes (which you also need to write from scratch).

conclusion: it really depends on your requirements. if your implementation is small/simple then this might be a good idea. but growing on a small idea will be hard with this approach. a more OO approach will set you up much better for refactoring/expanding later. this pattern is also older/antiquated. object querying IQueryable/LINQ is more popular and will become a wider standard shortly. i'd suggest u jump on board this wagon. it will be better for your personal development in the long run too. :D

some links:

• try aspnet MVC - http://www.asp.net/learn/mvc-videos/video-360.aspx?redir=true
• http://www.asp.net/learn/mvc-videos/video-361.aspx?redir=true
• http://www.asp.net/learn/mvc-videos/video-395.aspx
• if your scope is bigger, this will be a good start with handy patterns - http://www.asp.net/learn/mvc-videos/video-350.aspx

Answer 2

I fully recommend NOT USING DATATABLES. Look into a domain driven design implementation that your entire framework will work with regular objects that you can past into List<> or Queryable<> (for .NET 3.5). DataTables are garbage that shouldn't even be included in .NET anymore.

I would also recommend looking into using a Dependency Injection / Inversion of Control framework such Microsoft Unity or StructureMap to create loosely coupled code.