Pass data between layers RRS feed

  • Question

  • Hi all,

    I a am newbie here.

    My Tech. environment: 2.0 and Sql Server

    Manyatimes, we need to return data from different tables in the database to the UI (for example, search results) whose schema wouldnt match with any of the domain objects.

    In this case, one option is to transfer the data using the datasets/datatables feature provided by .Net.

    The other option I could think of is to create business (DTO?) objects to just pass on the data from the DB to the UI.

    I prefer the second approach. However, I need suggestions on how do I implement it? Will this DTO contain a reference of all the domain objects involved or Can I just include only the desired columns?

    Or, do we have any other solution?

    Thanks in advance,


    Friday, August 17, 2007 7:30 AM

All replies

  • If you're not going to use the ADO objects (DataSet/Table/etc.) in the application except to pass data from the DAL to a domain model, yes, absolutely, get rid of them.  It's a lot of unnecessary overhead.


    If you are creating a domain model, populate the data in the domain model directly from a data reader.  My favorite way of doing this while maintaining loose coupling is using what was popularized as the "provider model."  The essence of it is defining a data provider contract in your domain model layer that specifies how your application needs to get its data.  Then you have your DAL implement that contract.  You use configuration and/or runtime dependency injection to specify the provider you're using, so the domain model layer has no hard reference to the DAL.  The DAL does have a hard reference to the domain model layer (because it needs to implement the contract), but that's okay.


    You can simplify your architecture, if you know you don't need to switch/have multiple data providers, by just coding the DAL in the domain model project and calling the DAL directly (eliminating the need for the contract and configuration/runtime specification of provider).  This is tightly coupling the layers, though, so you should only take this approach if there is very low probability that you'll ever need to change the DAL (which is actually common in LOB apps).  Even so, this is a major compromise, and creating a contract is not that hard, nor is implementing it, so in general, I'd advise taking the more loosely coupled approach in most situations.


    As for DTOs, they can be a necessary evil in some architectures.  Generally speaking, I prefer to keep the data on/with my domain objects and have the DAL create/populate my DOs directly.  But as discussed in a recent thread here on Web services, you may find yourself in a situation where separating the data into separate objects becomes desirable so that you don't break OOD principles in your domain model just for the sake of serialization mechanisms.  Using DTOs creates extra work (extra types) and generally bloats the system, IMO, so I try to avoid them if possible.

    Friday, August 17, 2007 1:59 PM


    As I understand your need is to do something of the sort


    Select * from tableName


    where tableName is provided at run time.


    Here is how I would do it


    Make a SP GetData( tableName) whose body is

    query = 'Select * from '+tableName

    execsql query

    Make a SQL Server report which executes this SP



    Friday, August 17, 2007 4:36 PM
  • Hi,

    If i would you, I would use DTO as an base paradigm passing data between various layer, DTO can be directly tied to presentation, Business and Database, usually since multiple team work on a project we have something called Presentation Entity, Business Entity and Data Entity and if we are using Services, it may be referred as ServiceEntity.


    In most of my projects, I also put basic business validation on the data the entity, so that they can be used across the layers, irrespective of who fills the data, presentation or Data.


    Additionally apply generics to fill in the base call for the entity and decorate you entities with the Database file name specially for DB entities, so that you can use reflection and use a generic method to fill the entities.


    Entity ensures chunky calls, doing this make sure that you can expose your business using web services also


    Hope it help


    Vivek Puri


    Saturday, August 18, 2007 1:10 AM
  • Definitley sounds like you should consoder using codegeneration.

    From my personal experience you should defionitley look at

     NHibernate is also good if you performance is not the top of your priority list.


    Saturday, August 18, 2007 1:35 AM
  • If you are using different join SPs and each one is returning you the result set with different set of columns  then going for DTO approach may put you in lot coding effort. In this situation, to get work done more quickly, 
    I could opt for DataTable (which is much ligther version than DataSet and greatly improvised in dot net 2.0 and above), You could use it as a generic DTO for all layers and it also offers easy data binding with any dotnet controls. If you are looking for long term, scalable solution then "Provider model" would be the one to consider.

    - Pavan Gayakwad
    Saturday, August 18, 2007 9:58 AM
  • I agree with PavanGY on using the provider model, but I think if you use a code generator like .NETTiers it will give you a great head start, plus it is built using the provider model and Enterprise Library.


    Sunday, August 19, 2007 4:38 PM