none
My business model VS EF Model First RRS feed

  • Question

  • Hello,

    I got a bit confused with these terms, "My business model" and  "EF Model First"

    I made a buseiness model that includes classes inheriting from and associating to each other.

    Now I got to know that it is possible to create a Model that is possible to transform to databases with help of EF technology.

    Must I anyway primarily create my classmodel  prior to creating "Model First" in EF. If NOT, why not?

    Please answer me more extensively.

    Regards!

    Sunday, April 27, 2014 7:18 PM

Answers

  • I am going to keep it simple for you. You need to forget about using the model first approach. You need to address the database schema  from a database management solution standpoint like MS SQL Server Management Studio and create the tables with relationships. After that, you use the EF database first approach where EF creates the ORM model from the database schema, with you out of the picture.

    That is an immediate separation of the ORM model from any other model you may be thinking about.     

    This Domain/Business object model is about business objects that validate data,  call upon other business objects to do things like get or persist data, call a Web service and things of that nature.

    I am also going to suggest that you use Entity-2-DTO, point to the model created using DB first approach and use Entity-2-DTO to make the DTO(s) with relationships with other DTO(s) needed and you use the DTO(s) and not the EF entities up at the UI. You use the mapping functions of Entity-2-DTO to map from the EF entities to the DTO(s) and map DTO(s) back to EF entities for CRUD operations with the database with EF

    http://visualstudiogallery.msdn.microsoft.com/655aa6d4-4461-42ea-aeec-64cdb1313de7

    Use the DTO(s) and leave the EF entities behind at the data layer. 

    http://en.wikipedia.org/wiki/Data_transfer_object

    I worked on a recent contact using EF where the lead developer was trying to come with some domain model. That complicated domain model he had was all blown out of the water with the introduction of DTO(s) into the solution. His domain model became a simple model using the DTO(s), and his domain model was only concerned about business behavior and nothing else -- no relationships between domain model objects, which has you confused.

    • Marked as answer by Muris Friday, May 2, 2014 8:08 AM
    • Unmarked as answer by Muris Tuesday, May 6, 2014 2:45 PM
    • Marked as answer by Muris Tuesday, May 6, 2014 2:47 PM
    Monday, April 28, 2014 11:58 PM

All replies

  • I got a bit confused with these terms, "My business model" and  "EF Model First"

    I suggest that you don't confuse the Domain Model/Business Model with the ORM Model. They are two different models with different functionalities.  

    http://www.mehdi-khalili.com/orm-anti-patterns-part-4-persistence-domain-model

    Sunday, April 27, 2014 9:14 PM
  • Ok, let me ask like this:

    Is Model I build in EF tech my business model?

    or

    Is it  just a model I use to create my database and must keep developing my businessmodel. What I react on is that I can inherit entities/ classes when I create Model that will be pattern for creation of my databases

    Regards 

    Monday, April 28, 2014 6:49 AM
  • Ok, let me ask like this:

    Is Model I build in EF tech my business model?

    No the EF model is not a domain/business model in Domain Driven Design. The EF model is an ORM model. The virtual ORM model's  job is to persist data through the usage of objects on the virtual to the database. Those objects and their job are to do CRUD operations with the database. Those objects have methods/behavior to work with the database directly.

    or

    Is it  just a model I use to create my database and must keep developing my businessmodel. What I react on is that I can inherit entities/ classes when I create Model that will be pattern for creation of my databases

    Your Domain/Business objects can use objects within the domain that have nothing to do with the database.

    Again, do not confuse the two models the Domain model as opposed to the ORM model. They are two different models with two different functionalities. The Domain objects have business solution behaviors and they can use the ORM model objects to do CRUD operations with the database. The ORM model objects work with the database strictly  

     

    Monday, April 28, 2014 11:59 AM
  • Ok,

    Thanks :)

    It is always good to discuss even if everything is obvious and clear..

    I work on a WPF project where Observablecollection is used instead of List of entities when depicting one to many relationsship. Is it something I must pay attention to when modeling EF Model? I quess NOT although it belongs to my businessmodel?

    Thanks:) 


    • Edited by Muris Monday, April 28, 2014 2:01 PM
    Monday, April 28, 2014 1:52 PM
  • I am going to keep it simple for you. You need to forget about using the model first approach. You need to address the database schema  from a database management solution standpoint like MS SQL Server Management Studio and create the tables with relationships. After that, you use the EF database first approach where EF creates the ORM model from the database schema, with you out of the picture.

    That is an immediate separation of the ORM model from any other model you may be thinking about.     

    This Domain/Business object model is about business objects that validate data,  call upon other business objects to do things like get or persist data, call a Web service and things of that nature.

    I am also going to suggest that you use Entity-2-DTO, point to the model created using DB first approach and use Entity-2-DTO to make the DTO(s) with relationships with other DTO(s) needed and you use the DTO(s) and not the EF entities up at the UI. You use the mapping functions of Entity-2-DTO to map from the EF entities to the DTO(s) and map DTO(s) back to EF entities for CRUD operations with the database with EF

    http://visualstudiogallery.msdn.microsoft.com/655aa6d4-4461-42ea-aeec-64cdb1313de7

    Use the DTO(s) and leave the EF entities behind at the data layer. 

    http://en.wikipedia.org/wiki/Data_transfer_object

    I worked on a recent contact using EF where the lead developer was trying to come with some domain model. That complicated domain model he had was all blown out of the water with the introduction of DTO(s) into the solution. His domain model became a simple model using the DTO(s), and his domain model was only concerned about business behavior and nothing else -- no relationships between domain model objects, which has you confused.

    • Marked as answer by Muris Friday, May 2, 2014 8:08 AM
    • Unmarked as answer by Muris Tuesday, May 6, 2014 2:45 PM
    • Marked as answer by Muris Tuesday, May 6, 2014 2:47 PM
    Monday, April 28, 2014 11:58 PM