none
Pass Data...N-Tier RRS feed

  • Question

  • Hi everyone how is it going? What is best practices to pass data between tiers and still keep things loosly coupled. I also want something that will serialize across service boundaries. I have pondered this question for awhile and here are some things ive came up with:

    1) Linq To SQL / Entity Framework is too hard at this point to be effective in a N-Tiered architecture. To keep everything working smoothly you either have to tightly couple everything or write a lot of code to get around the fact that your going to be disconnecting from the datacontext. I will wait for version 2 Smile.

    2) You can pass around Data Entities (POCO Objects). You essentially create an array of poco objects and pass that between tiers. I liked this approach.

    3) Dataset - Two types of datasets were under consideration...typed and untyped. I didn't like the untyped approach but thought the typed approach was maybe an option.

    So for me i decided to go with an array of POCO objects then when i was mplementiong this soulution i came up with a small problem. I was using the SQLDataReader. Well i didn't know how big my array was going to be until i was done iterating through my datareader. I determine how big i needed to make the array for my POCO objects. I sure didn't want to have to redimention the array for every iteration through the datareader.
    Could soeone give me some general guidance on what is a good solution to pass data back and forth between tiers. I wanted to use the SQLDataReader because of the low overhead but i don't know if i can because i need a rowcount. Any help would be appreciated.

    thanks,
    Ncage
    Monday, July 7, 2008 1:46 AM

Answers

  • Hi Ncage,

         I would recommend option 2 as well.  Here are my reasons.

     

         POCO will be small to be transmitted over wire/layers with less overhead on the application performance.  POCO property getters and setters would only check for boundary validations (similar to table constraints) hence some sanity is there in the POCO, but it does not morph into business layer.  If you look at my architecture diagram at http://gajakannan.com/netarch.aspx, the POCO is what my Domain/Model entity layer that is shown as vertical gray block.

     

         DataSet, DataTable or any form of System.Data is heavy to be crossing layers..

        

         The only difference from your model and my model is that I use LinQ to when I traverse through my entity objects, there by using the power of SQL like language to manage the information in my Entity objects (POCO in your case).

     

    Hope this helps.

    Monday, July 7, 2008 5:24 PM
  • Thats why I use LINQ to perform those activities for me.  Also, I use collection instead of Array of my POCO.
    Monday, July 7, 2008 9:23 PM

All replies

  • Hi Ncage,

         I would recommend option 2 as well.  Here are my reasons.

     

         POCO will be small to be transmitted over wire/layers with less overhead on the application performance.  POCO property getters and setters would only check for boundary validations (similar to table constraints) hence some sanity is there in the POCO, but it does not morph into business layer.  If you look at my architecture diagram at http://gajakannan.com/netarch.aspx, the POCO is what my Domain/Model entity layer that is shown as vertical gray block.

     

         DataSet, DataTable or any form of System.Data is heavy to be crossing layers..

        

         The only difference from your model and my model is that I use LinQ to when I traverse through my entity objects, there by using the power of SQL like language to manage the information in my Entity objects (POCO in your case).

     

    Hope this helps.

    Monday, July 7, 2008 5:24 PM
  • Thanks for the reply. How do you go about dimensioning your array since you can't get a rowcount out of the datareader?
    Monday, July 7, 2008 6:50 PM
  • Thats why I use LINQ to perform those activities for me.  Also, I use collection instead of Array of my POCO.
    Monday, July 7, 2008 9:23 PM
  • Are you using stored procedure to get the data? pass a out parameter which will return count.

    Thursday, August 14, 2008 11:08 AM