none
Advice for Migrating n-tier Architecture and inhouse ORM to EF4 and a Suitable Architecture / Design Pattern

    Question

  • Hi,

    I'm looking for some advice and hopefully some useful resources to help me out.

    I'm currently working on some structured guidelines for my team as we are moving to EFv4 for new greenfield development work (95% of our development is web development). Our previous approach to systems development involved in its purest sense the following:

    1.     A SQL Server Database

    2.     A Data Layer which consisted of two class libraries which used an in-house developed ORM to populate and manage 'Element' objects (very similar to 'Entity' objects).

    3.     A Business layer which consisted of one or more class libraries containing all the business logic for the application.

    4.     A Presentation layer which was generally a website.

    I’ve been investigating EFv4 with the n-tier framework but it’s difficult to find consistent and useful information. I have been reading ‘Programming Entity Framework 2<sup>nd</sup> Edition’ by Julia Lerman which is very good. From this I have ascertained that first I need separation of concerns. Julia also talks about the Repository Pattern as a very good pattern particularly for unit testing which is something I also want to start using.

    So far I am thinking of using POCO Entity classes generated using Microsoft’s T4 template with slight modifications to split the Entities off into a separate project from the context without a reference to System.Data.Entity. I will then use the Repository Pattern to give an n-tier style structure to the application. If I then want to use Silverlight for the front end I can use WCF RIA Services and MVVM.

    How does this sound for a good migration over from our existing architecture? Should I be considering a different approach or a different architecture and most importantly can someone point me in the right directions for some good working examples of these patterns as Julia Lermans example is rather hard going and makes a lot of assumptions?

    Thanks

    Stephen 


    Stephen
    Thursday, January 06, 2011 2:54 PM

Answers

  • Hi Stephen,

    Welcome to EF forum!

    I am very glad to hear that you are interested in EF4 and have finished reading Julia's book.  I agree that it's really a great and helpful book.   

    I don't have much experience on webdev, but I do believe EF4 can play a vital role in n-tier apps like what you are building.   Besides the POCO entities and Repository Pattern, I would also recommend you consider the Self Tracking entities (STEs) in n-tier apps.   Here are some references:
    http://msdn.microsoft.com/en-us/library/bb896304.aspx
    http://www.ef-faq.org/serialization-and-web-services.html

    I am also looking forward to other community members' ideas.

    Have a nice weekend!

    Thanks


    Michael Sun [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, January 07, 2011 5:48 AM
  • Hi,

    Thank you Michael for your helpful reply.

    I have been reading up on Self Tracking Entities (revisiting chapter 18 in Julia’s book and searching the forums). STE’s do look appealing and would fit our requirements as our client applications will most certainly be .NET (although who knows what the future holds, mobile development etc.) but I’m coming to contradicting conclusions.

    I’ve heard mention that Self tracking Entities are best fit for an n-tier architecture but simple POCO entities are better for web applications as STE’s need to be persisted between postbacks using the viewstate or session. This however seems to fit quite well if you are following MVC. Julia does point out though that problems can arise when using STE’s with WCF RIA Services as this technology has its own change-tracking mechanism.

    The main difference between using Simple POCO and Self tracking Entities at the basic level seems to be that with STE’s I need to write extra code for my entities to provide state information whereas using Simple POCO with ‘virtual’ properties I can use the runtime generated proxy’s to manage state. The key seems to be communicating with the client. With STE’s I don’t need to consider state as it’s bundled into my Entity but with Simple POCO I need write extra code in the middle tier (unless I’m using WCF RIA Services which will handle state for me).

    Am I thinking along the right lines or have I completely missed the point? As for guidelines for my developers I’m thinking it’s not a good idea to force them down one path or the other with regards to Simple POCO and Self Tracking Entities as long as they are consistent throughout the project.

    Any thoughts on patterns for n-tier development? Should I be giving some considerations to patterns other than the Repository pattern?

    Thanks

    Stephen

     


    Stephen
    Friday, January 07, 2011 2:47 PM
  • I’ve heard mention that Self tracking Entities are best fit for an n-tier architecture but simple POCO entities are better for web applications as STE’s need to be persisted between postbacks using the viewstate or session. This however seems to fit quite well if you are following MVC. Julia does point out though that problems can arise when using STE’s with WCF RIA Services as this technology has its own change-tracking mechanism.

    The main difference between using Simple POCO and Self tracking Entities at the basic level seems to be that with STE’s I need to write extra code for my entities to provide state information whereas using Simple POCO with ‘virtual’ properties I can use the runtime generated proxy’s to manage state. The key seems to be communicating with the client. With STE’s I don’t need to consider state as it’s bundled into my Entity but with Simple POCO I need write extra code in the middle tier (unless I’m using WCF RIA Services which will handle state for me).


    Stephen


    Hi Stephen,

    I would agree on your understanding.  From your description in the first post, I think Repository pattern is a good way to go.  Also, recently I am working on a similar project too.   Repository pattern is used in our project.  The only difference is that we are using WCF services directly instead of WCF RIA Services since we think there are more customization in WCF than in WCF RIA Services. :)  

    What's the best design pattern is always a "hard-to-say" problem.   I believe the most fit is the best. 

    Good day!

    Thanks


    Michael Sun [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, January 10, 2011 2:11 AM

All replies

  • Hi Stephen,

    Welcome to EF forum!

    I am very glad to hear that you are interested in EF4 and have finished reading Julia's book.  I agree that it's really a great and helpful book.   

    I don't have much experience on webdev, but I do believe EF4 can play a vital role in n-tier apps like what you are building.   Besides the POCO entities and Repository Pattern, I would also recommend you consider the Self Tracking entities (STEs) in n-tier apps.   Here are some references:
    http://msdn.microsoft.com/en-us/library/bb896304.aspx
    http://www.ef-faq.org/serialization-and-web-services.html

    I am also looking forward to other community members' ideas.

    Have a nice weekend!

    Thanks


    Michael Sun [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, January 07, 2011 5:48 AM
  • Hi,

    Thank you Michael for your helpful reply.

    I have been reading up on Self Tracking Entities (revisiting chapter 18 in Julia’s book and searching the forums). STE’s do look appealing and would fit our requirements as our client applications will most certainly be .NET (although who knows what the future holds, mobile development etc.) but I’m coming to contradicting conclusions.

    I’ve heard mention that Self tracking Entities are best fit for an n-tier architecture but simple POCO entities are better for web applications as STE’s need to be persisted between postbacks using the viewstate or session. This however seems to fit quite well if you are following MVC. Julia does point out though that problems can arise when using STE’s with WCF RIA Services as this technology has its own change-tracking mechanism.

    The main difference between using Simple POCO and Self tracking Entities at the basic level seems to be that with STE’s I need to write extra code for my entities to provide state information whereas using Simple POCO with ‘virtual’ properties I can use the runtime generated proxy’s to manage state. The key seems to be communicating with the client. With STE’s I don’t need to consider state as it’s bundled into my Entity but with Simple POCO I need write extra code in the middle tier (unless I’m using WCF RIA Services which will handle state for me).

    Am I thinking along the right lines or have I completely missed the point? As for guidelines for my developers I’m thinking it’s not a good idea to force them down one path or the other with regards to Simple POCO and Self Tracking Entities as long as they are consistent throughout the project.

    Any thoughts on patterns for n-tier development? Should I be giving some considerations to patterns other than the Repository pattern?

    Thanks

    Stephen

     


    Stephen
    Friday, January 07, 2011 2:47 PM
  • I’ve heard mention that Self tracking Entities are best fit for an n-tier architecture but simple POCO entities are better for web applications as STE’s need to be persisted between postbacks using the viewstate or session. This however seems to fit quite well if you are following MVC. Julia does point out though that problems can arise when using STE’s with WCF RIA Services as this technology has its own change-tracking mechanism.

    The main difference between using Simple POCO and Self tracking Entities at the basic level seems to be that with STE’s I need to write extra code for my entities to provide state information whereas using Simple POCO with ‘virtual’ properties I can use the runtime generated proxy’s to manage state. The key seems to be communicating with the client. With STE’s I don’t need to consider state as it’s bundled into my Entity but with Simple POCO I need write extra code in the middle tier (unless I’m using WCF RIA Services which will handle state for me).


    Stephen


    Hi Stephen,

    I would agree on your understanding.  From your description in the first post, I think Repository pattern is a good way to go.  Also, recently I am working on a similar project too.   Repository pattern is used in our project.  The only difference is that we are using WCF services directly instead of WCF RIA Services since we think there are more customization in WCF than in WCF RIA Services. :)  

    What's the best design pattern is always a "hard-to-say" problem.   I believe the most fit is the best. 

    Good day!

    Thanks


    Michael Sun [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, January 10, 2011 2:11 AM
  • Hi Stephen,

    Any update on this thread?   If you need any further assistance, please feel free to let me know.

    Good day!

    Thanks


    Michael Sun [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, January 12, 2011 1:21 AM