3 (N) tiered solutions RRS feed

  • Question


    ok, i have always envisaged and devloped my .net web apps in 3 tier flavor (presentation, Business Logic, Data Access) but recently i've seen a few articles which have made me re-rhink my thoughts on what a DAL is.


    My original thinking was that no layer should know (or care) about an upper layer, i.e. my DAL's never cared about the other layers of my app (not my custom classes or their properties), they accepted scalar values as parameters and returned either dataSets or DbDataReaders to the BLL.


    Now i am wondering, should i create a common business object (i.e. class template) layer, and let it be seen by any application tier, and furthermore should i map data returned from stored procs directly in my Data Access tier. i.e. is it acceptable design to pass and receive custom classes into and out of my data access tier?


    I can obviously see the benefits in terms of de-coupling, but are there any major drawbacks i am not seeing??


    what about validation? surely this should be performed on the Businees object prior to being deemed acceptable to pass to the data access layer?



    any thoughts and opinions wqould be well appreciated.



    Thursday, October 30, 2008 1:25 AM

All replies

  • Hi,


    I think you are heading towards the correct direction here...


    It is true the one layer should not care about other layer (generally), although each layer should be aware of the layer above and below them.  So a presentation layer would be aware of BL, and BL be aware of presentation and DAL and DAL aware of BL...  Aware = decoupling and creating cohesion, not tightly coupling.


    I am usually not a fan of sending datasets/datareaders across layers although there are others that would advocate it.  My recommendation is to create a common business object layer (which is also called as Model/Entity/Domain objects) that cuts across layers.  Take a look at the architecture diagram I have published at http://gajakannan.com/netarch.aspx.


    The only tradeoff between using entity objects Vs datasets is that entity objects has initial high development cost but diminishing maintenance cost.  On the other hand dataset gets you up and running quickly but higher maintenance costs in the long run.  Also datasets/datareaders are heavy to send it across the wire/process boundaries especially if your application is very chatty among layers.  Depending on your specific requirements, developer skill sets and infrastructure setup you are probably in a better position to weigh-in these options and decide what works best for you.


    { Gaja; }


    Thursday, October 30, 2008 3:18 AM
  • I would suggest you to have a look at "Dependency Inversion Principle," that states:

    1. First design the interfaces of a lower-level layer and then implement it.
    2. A high-level layer (in your case, BL) must not directly depend upon a lower-level layer (in your case, DAL). Rather, both these layers must be depending/adhering onto the contract (in your case, Interfaces in BL) established between them.

    By following this principle, your design would be more extensible, as experts say.


    For the dispute of dealing Datasets in BL: Yes, its not a good practice. We can use a hybrid of "Data Mapper" and "Facade" patterns to come across this problem. So, we would be having a separate layer which maps Datasets to Business entities.


    Good luck !!



    [ Prem ]


    Thursday, October 30, 2008 6:18 AM
  • I have also read and seen this type of solution. Very clean and separated. Data layer returns datasets/tables to a mapping layer, that maps to BO's and then passes these up. Another solution is to use DTO's instead of datasets/tables.


    But I do not think the you will get the reward for this investment of time/money. For each BO you have to have a mapper. Thats x2 classes/methods. And when changes occur, the change complexity increases. More code, more bugs, more to maintain.


    I usually go for a common domain model layer with entities that the data layer gets / returns I think is a efficient, still clean solution. And if you add to much overhead to an architecture, it is in lean terms 'waste'.


    I also like the domain driven approach, design the domain model, design the repository needs, then design data layer/database.


    That's me atleast. But ofcourse it depends on the size and demands on the solution architecture.




    Monday, November 3, 2008 2:05 PM
  • Yes. It purely depends upon the size of the solution.


    For an enterprise application that has more complex business rules, the Domain Driven approach is the best one, and we have all those O/R mapping tools (NHibernate, LINQ etc..) to ease and trash out the Data Access layer almost altogether.


    The approach of common domain model layer is the one that I usually go for- thanks to MrMartin to chance me to clarify my post. The problem mentioned in the initial post was about the UI layer speaking in terms of DataSets and thats why I hinted about Mappers.


    [ Prem ]

    Wednesday, November 5, 2008 6:31 AM