none
WPF MVVM + Entity Framework: Should the Model layer depend on Database access layer? or should Data access layer depends on model layer?

    Question

  • Our application is a window application which uses WPF, MVVM pattern, Entity framework 4, data stroage contains both SQL server compact edtion and xml files.

    We treat entity data model generated entities (we call EF-entities) as data model layer

    Since the whole application is running in single PC with limit pc power. We do not care decoupling like web application (separating client application with server application and use WCF service between client app and server app and pass POCO or DTO through WCF service. ViewModel only references DTO). In our case, our application is pretty small and we do not want to intruduce more layer to complicate it. So we directly reference EF-entities in Viewmodel layer 

    Data access layer which includes CRUD (CreateNewCustomer, UpdateCustomer, DeleteCustomer, GetCustomers(). etc). It will reference EF-entities such as Customer in the class like IEnumerable<Customer> GetCustomers()

    Inside the Data access layer it will call Entity framework ObjectContext to query or update data by using Link to Entity (In our case, we combine DataAccess layer and DataAccess class describe) into one class called DataAccessLayer.

    Ref the other thread: http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/2280d4b0-f800-475d-9626-36a23932402a

    We have drawed a layer diamgram to descibes our layer architecut (bottom up)

    1) database links to Entity data model which includes EF-entities

    2) Data Access layer depends on the Entity data model (includes EF-entities class).

    3) ViewModel references the DataAccesslayer to get collection of customers.

        ViewModel also directly referece EF-entities such as ObserverableCollection<Customer> and bind to the view's listbox.

    During our design review of application architecture, other group developers start question us

    Should the Model layer depend on Database access layer? or should Data access layer depends on model layer?

    In our case, we answer that Data access layer depends on model layer.

    Today we went the RockStars events in Microsoft store in Mission Viejo (California). One of speaker mentioned that Entity Data model is data access layer. He thinks that GetCusotmers() in our data access layer is data service layer

    So in genearal, should we treat entity data model as data access layer or should we treat entity data model as model layer? Or Entity data model play both model and data access layer roles?


    JaneC

    Monday, April 11, 2011 4:58 AM

Answers

  • I notice that a lot of developers have issues on how to apply the MVVM pattern in an n-tier application, so I wrote an article about it. You can find it here.
    Geert van Horrik - CatenaLogic
    Visit my blog: http://blog.catenalogic.com

    Looking for a free open-source MVVM framework for WPF, Silverlight and Windows Phone 7? Check out Catel!
    • Marked as answer by JJChen Friday, April 15, 2011 1:03 AM
    Monday, April 11, 2011 7:14 AM
  • No, the Entity Data Model Library is the DAL. Converting an entity into an interface is not a huge hit on performance. You can even "trick" the system and use the actual DAL objects inside your UI as interfaces without casting them to DTO objects. To do this, you need to do the following:

    Create or generate an interface ICustomer in the "cross cutting concerns library". Then, let the DAL Customer entity implement the ICustomer interface. In the BL and UI, only use the ICustomer to handle data.

    This way, you don't have to convert to/from DTO objects, but still don't include the DAL in your UI layer. The only "downside" is that you are actually messing with your DAL objects inside the UI, but that's something that can be forgiven :)


    Geert van Horrik - CatenaLogic
    Visit my blog: http://blog.catenalogic.com

    Looking for a free open-source MVVM framework for WPF, Silverlight and Windows Phone 7? Check out Catel!
    • Marked as answer by JJChen Friday, April 15, 2011 1:04 AM
    Monday, April 11, 2011 7:19 PM

All replies

  • I notice that a lot of developers have issues on how to apply the MVVM pattern in an n-tier application, so I wrote an article about it. You can find it here.
    Geert van Horrik - CatenaLogic
    Visit my blog: http://blog.catenalogic.com

    Looking for a free open-source MVVM framework for WPF, Silverlight and Windows Phone 7? Check out Catel!
    • Marked as answer by JJChen Friday, April 15, 2011 1:03 AM
    Monday, April 11, 2011 7:14 AM
  • Hi Geert,

    Thanks for providing the link!

    In the section 4.2 n-tier application you mention the Good situation and Wrogn situatioin as following:

    When applications become more and more complex, users start to demand more functionality and probably business rules. When writing larger applications, it is recommended to write a 3-tier application to separate the business rules from the DAL. Below is a graphical representation on how MVVM fits into the 3-tier architecture:

    As you can see, the DAL does not participate in the MVVM at all using a 3-tier application. This is due to the fact that the business layer provides DTO objects that are used as Models, and transforms these DTO objects into entities that the DAL can handle. We see a lot of users referencing the DAL from the UI-layer, but this is wrong. Below is a graphical representation of a good and bad situation of the 3-tier architecture:

    Good situation

    In the good situation, you see that the UI layer uses the BL, and the BL uses the DAL. A top-layer can always use a lower “down-the-hill”. A lower layer may never use a layer above (which is situated in the “very wrong” situation).

    Because the DAL is not referenced at all, it is required to create data transfer objects (DTOs) to represent data from the DAL in the BL. The DTO objects are defined inside the BL so the BL is responsible for translating entities from the DAL into DTO objects which are accessible from the UI layer.

    Wrong situation

    The wrong situation shows a “solution” we see a lot. Developers that use this approach are not aware of the n-tier layers and directly reference the DAL in the UI layer. This way, they don’t have to create custom DTO objects.

    If you don’t want to write custom DTO objects, the only option you have is to write a cross-cutting concerns library which can be used by all layers. In the cross-cutting concerns, you can write interfaces for all the entities of the DAL and use these in the BL and UI layer.

    Nowadays, most people use ORM mappers. ORM mappers can be used to generate source code for the DAL so you don’t have to spend writing this layer yourself. A tip is to customize the templates for the ORM mapper of your choice (if it is supported by the mapper) so it also generates the DTO objects for you.

     ----------------

    We implement our application in your "Wrong situation".  The reason is that our application is more conerning about performance. We do not want to create more layers to sacrifice the performance. In most cases, we do not create DTO objects. Instead, we directly reference objects call EF-Entities,  which ADO.NET Entity Framework generats from mapping database tables in the Entity Data Model library, in the ViewModel layer (UI layer in your layer architecture). We assume this Entity Data Model library is the one you mention as "cross cutting concerns library".

     For each EF-Entity or subgroup of EF-entities, we create a xRepository class such as CustomerRepository class. This class includes CRUD (CreateNewCustomer, UpdateCustomer, DeleteCustomer, GetCustomers(). etc). It will reference EF-entities such as Customer in the class like IEnumerable<Customer> GetCustomers()
    {
        return (from c in EntityContext.Customers
                              where c.CustomerID > 0
                              select c).ToList();
    }

     We define CustomerRepository class as singleton and reference it in the CustomerViewModel class.

    In our understand of DAL, DAL will hide persist detail from interface. No matter the customers data is stored in database or in xml file. GetCustomers() will provides collection of customers back.  In this point, we think that CustomerRepository is the DAL. As we treat CustomerRepository as DAL, our implemention is in your "Wrong situation" layer architecture with a little difference  where taht DAL will use Model layer.

    Do we interprete something wrong here?

    Our question is that should we treat CustomerRepository class as DAL or should we treat it as BL?

    Should we treat Entity Framework generated Entity Data Model classes which include EntityContext.Customers as DAL?

    • Edited by JJChen Monday, April 11, 2011 8:38 PM
    Monday, April 11, 2011 6:56 PM
  • No, the Entity Data Model Library is the DAL. Converting an entity into an interface is not a huge hit on performance. You can even "trick" the system and use the actual DAL objects inside your UI as interfaces without casting them to DTO objects. To do this, you need to do the following:

    Create or generate an interface ICustomer in the "cross cutting concerns library". Then, let the DAL Customer entity implement the ICustomer interface. In the BL and UI, only use the ICustomer to handle data.

    This way, you don't have to convert to/from DTO objects, but still don't include the DAL in your UI layer. The only "downside" is that you are actually messing with your DAL objects inside the UI, but that's something that can be forgiven :)


    Geert van Horrik - CatenaLogic
    Visit my blog: http://blog.catenalogic.com

    Looking for a free open-source MVVM framework for WPF, Silverlight and Windows Phone 7? Check out Catel!
    • Marked as answer by JJChen Friday, April 15, 2011 1:04 AM
    Monday, April 11, 2011 7:19 PM
  • So Entity Data Model library is the DAL.

    Since we create CustomerRepository class, we will not mess our DAL object (in our case the EF-Entities) in the UI (ViewModel layer). Any CRUD action will be go through CustomerRepository class.

    Should we treat CustomerRepository class belongs to model layer?

    Should we treat CustomerRepository class is Data Service layer just like the WCF service, but it does not belong to Model layer?


    JaneC
    Monday, April 11, 2011 10:39 PM
  • See article 1

    See article 2


    Geert van Horrik - CatenaLogic
    Visit my blog: http://blog.catenalogic.com

    Looking for a free open-source MVVM framework for WPF, Silverlight and Windows Phone 7? Check out Catel!
    Monday, April 11, 2011 10:58 PM
  • Thanks Geert for the helpful articles!

    Hi JJChen, have you checked those references? If you still have any concerns please kindly post back and let us know.

    Best regards


    Yves Zhang [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.

    Thursday, April 14, 2011 3:50 AM
  • Good article about Data access layer: 

    .NET Application Architecture: the Data Access Layer by Damon Armstrong
     

    http://www.simple-talk.com/content/article.aspx?article=253

     


    JaneC
    Wednesday, April 20, 2011 6:01 PM