nTiering: Seperating DAL from Presentaion RRS feed

  • Question


    I am currently working on a project that is going to work with numerous rows of data from a database backend, and send said rows back to a requestor.


    Currently my tiers look as follows

    -- Data Layer (SQL Database)

    -- Data Access Layer (.net 2.0)

    -- Business Layer (.net 2.0)

    -- Presentation Layer (.net 2.0)


    But I have ran into an interesting architecture problem: how do I get the performance of a Data reader through my business layer to my Presentation layer without my Presentation layer knowing about my Data Access Layer Objects? (AKA something like the SqlDataReader object)


    I know I can read my data into a type specific dataset, and pass that to my presentation layer, where it will be formatted correctly for the presentation layer. But that means the DAL has to read ALL the data prior to passing it back through the business layer to the presentation layer to process it into the format my users want.


    If I just threw the SqlDataReader into my Presentation reader, it would probably fly! Each row that was received would be formatted simultaneously as more data is retrieved.


    So here is my question: What methods can you describe to handle this kind of scenario?


    Thanks in advance!


    Nathan Tregillus


    Wednesday, August 20, 2008 4:27 PM

All replies


    Ok, guess this is a harder question than I thought!


    I have been thinking about this and came up with this design:


    My DAL will have a method for returning IDataReader object that my Business Layer will use. This way I can use a SqlDataReader, or OracleDataReader, or any of the other data readers, and my Business Layer should never be the wiser, right?


    From there my Business Layer object will inherit the IEnumerable interface. This should allow my Presentation layer to utilize my Business Layer object as a collection, even though all the data might not be completely received.


    For my Presentation Layer to use a for-each to loop through the data to format it.


    What do you guys/gals think? I am winging this as I write this entry, so I haven't actually coded it this way yet!



    Nate Tregillus


    Wednesday, August 20, 2008 7:23 PM
  • There are a number of threads on this forum relating to layered and n-tier applications. A link to one of the threads is below;




    Although, returning an interface will enable you to switch between an Sql and Oracle data reader, you will still be tied to a data reader.  If maintainability is a key requirement collections of objects could be returned to the presentaton layer.  There is nothing wrong with returning data reader from an n-tier perspective though.  This just isn't seperating the data access from the presentation layer completely.


    Also, as much of the formatting as possible is normally performed before the data gets to the presentation layer. 


    Hope this helps



    Thursday, August 21, 2008 10:20 AM

    Awesome! Thanks for the feedback. I have very little experience with n-tiering; this is my first attempt.


    I guess I kind of fudged the business layer with the presentation layer. I was thinking I needed to separate the method to present the data to my requestor (its XML) from the actual business logic, so that I could potentially add different presentation layer, say present in a serialized Binary format, and all I would have to do is place the data in the business objects into the new serialization type project.



    This leaves me in an interesting vantage point: Data Readers are more memory efficient, and overall can improve speed if handling a large number of rows, BUT the concept of forward only collections really doesn’t exist (right?).


    See http://enerlinx.com/blog/archive/2005/08/25/229.aspx for the comparison I was reading between DataAdapters and DataReaders.



    I guess I just wanted the rows of data to flow evenly through the project, rather than Queuing the data up in objects (collections) between each layer.


    I appreciate the feedback!



    Thursday, August 21, 2008 3:52 PM
  • Notice that separation of layers usually decreases performance - it's purpose is to enable easier modifications and improve maintainability by separation of concerns, not to increase performance.


    Passing a DataReader to presentation layer will always be the most efficient solution, but quite dangerous at the same time. In that scenario Data Access Layer looses control over the DataReader instance, thus it looses control over a underlying database connection.

    You have no means to force Presentation Layer to close reader after using it - in such a case the database connection won't come back to the pool, what may lead to quite a few problems.


    To prevent above problem you need to think about Data Access Layer and its features designing and coding Presentation Layer - what actually means that you won't have these layers separated any more.


    Does it means that you should never use DataReaders in presentation layer? Of course not - but it is a design decision you have to make being aware of its results.


    Saturday, August 23, 2008 11:14 AM
  • I think whatever you pass back from the data access layer should be disconnected from the database.  Xml, obejcts or recordsets.


    There should be no connection to manage

    Saturday, August 23, 2008 5:00 PM
  • I completely agree - my point was that IF you pass DataReader to presentation layer, presentation layer stops be just presentation layer and becomes to some extent data layer as well.  


    In some cases this is acceptable (if it wasn't Microsoft shouldn't develop SqlDataSource in the first place), but in most middle-sized and large applications it is not.


    If you really want to have data, business and presentation layer separated, you should not pass DataReader between them.


    Sunday, August 24, 2008 4:32 PM
  • Hi !


    There are (at least) two types of patterns here. 


    One is the using of the DataReader, or one of its interfaces, in the presentation layer, which as mentioned several above, will couple the layers tighter.  It will also have a tendency to move business logic higher up in layers.


    Another pattern is the Domain Driven Design patterns (just google on it to learn about it, just too many hits :-)), where the business layer consists of domain objects, not untyped DataReaders or IEnumerable interfaces, but instead of Customer, Order, Invoice etc (if that's in the domain).  This leans you into making higher separation between the layers, and it makes your code much easier to understand (IMHO).  

    A business object like Customer MAY use a dataset as part of its Data access routines, but will not expose that to the higher layers, since the dataset belongs to even lower layers (The Data Access Layer).   Instead it will expose itself, or an interface to itself to the higher layers.


    -  terje  :-) 



    Thursday, August 28, 2008 8:21 PM