entity framework design RRS feed

  • Question

  • User680737545 posted


    I've started reading up on entity frameworks and am little confused after going through so many articles. I'd like to mix entity framework into my project in an 3-tier architecture model.

    It appears entity framework is mainly used in the business layer to represent entities in the database as this would replace the traditional custom class mapping. I've downloaded a sample solution and it has a model like the following:

    UI -- > Business Components --> Business Entities (Entity Framework) --> DAL (which has a reference to the Busines Entities project and it uses the Business Entitiy solution to process database transactions.

    Is this the correct approach? If this model is correct, does the entity framework model replace the traditional DAL approach as the Business Entities (Entity Framework) has methods to perform insert, update and delete operations.

    I've read articles which talks about entitiy framework being used in the DAL, are they referring to the approach above?

    Please do not refer me to other articles as the more i read the more confused i get.

    Thanks Heaps.

    Monday, January 18, 2010 7:29 PM


  • User-1179452826 posted

    The thing with architecture issues like this is that there are many more than one way to  skin a cat.

    It depends on what you need, really. EF v1 (and EF v4.0) is great at simple two tier designs. You create a context and the context does all the change tracking.

    Unfortunately, that's not really extensible, flexible, testable yadda yadda. EF v4.0 rectifies this a lot.

    In EF v4.0, you have support for the "previous" two tier design, as well as proxy tracking. The most attractive feature though is pure POCO support. For a domain driven design, I'd use POCOs along with a repository and unit of work pattern to abstract away anything related to EF specifically. I'd call the repository from my domain layer to carry out persistence tasks. I guess in this way, the domain layer is very storage-tech agnostic and testable, and the influence of EF or any other persistence tech won't cross the repositories into the domain layer. This will enhance the previously mentioned yadda yadda parts.

    You might want to take a look at the kigg project source code at codeplex. Kazi Manzur has done a pretty decent job with the architecture there.

    But again, there are more ways to skin a cat [:)]

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, January 19, 2010 1:14 AM