locked
Entity Framework - Existing Database, classes in seperate library RRS feed

  • Question

  • I'm looking for information about using entity framework with an existing database, but to keep my poco classes in another library.

    I've done this a number of times in the past, but I've always ended up with my model classes in my data access library using EF and my domain classes in a separate library.  Inevitably this meant writing code to translate between my domain classes and my model classes.  This seems pointless and inefficient since the classes are usually almost identical.

    Can anyone point me to a walkthrough keeping my classes are materialized by EF in a separate library?  I would need to be able to do some minor name correction (eg Filter_Rule --> FilterRule).  I would also like to be able to keep anything EF specific in the data access library so that I can swap out the data access library if I need to.

    Thanks,

    Jason


    • Edited by JDWilson Wednesday, May 4, 2016 6:40 PM
    Wednesday, May 4, 2016 6:39 PM

Answers

All replies

  • I'm looking for information about using entity framework with an existing database, but to keep my poco classes in another library.

    I use DB First, I don't use POCO(s) and I use DTO(s). The DTO(s) are in a classlib project called Entities. All projects that use the DTO(s) have project reference to Entities.

    I've done this a number of times in the past, but I've always ended up with my model classes in my data access library using EF and my domain classes in a separate library.  Inevitably this meant writing code to translate between my domain classes and my model classes.  This seems pointless and inefficient since the classes are usually almost identical.

    I always want an abstraction layer away from the ORM and the underlying DB technology. The Entities library with the DTO(s) is the abstraction layer. Any projects above the DAL only see the DTO(s).

    And one has to map form EF Entity to DTO and DTO back to EF Entities.

    That's why there are tools like Auto Mapper and Entity-2-DTO.

    http://cpratt.co/using-automapper-getting-started/

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

    And yes, I have done the mappings manually too.

     I would also like to be able to keep anything EF specific in the data access library so that I can swap out the data access library if I need to.

    If using the Entities classlib project with the DTO(s), then nothing above the DAL would even care. 

    Wednesday, May 4, 2016 7:42 PM
  • Thank you for your very thorough answer. Problem is that it didn't answer my question. What you describe is exactly what I'm doing except you use a tool to do the object translation. I've used tools to object translation, most IOC containers will do it. In my implementation of IOC, I tend to make by DAL dependent on by BAL. I'm pretty sure that EF can materialize my business objects, but I'm have trouble finding documentation about how to do about doing it.
    Thursday, May 5, 2016 2:33 PM
  • I tend to make by DAL dependent on by BAL. I'm pretty sure that EF can materialize my business objects, but I'm have trouble finding documentation about how to do about doing it.

    I suggest that you don't confuse domain objects with persistence objects.  EF, the (ORM), is dealing with persistence objects on the virtual model and not domain model objects in your business domain. Maybe, the reason you can't find any documentation about your subject is because  the ORM doesn't deal with domain objects.  

    Thursday, May 5, 2016 4:49 PM
  • I'm not.  But understand there is nothing that says it can't.  Its just a mapping issue. 

    Let's face it -- it's nice to have an abstraction layer that doesn't require that our persistence layer match our domain layer, but there are many times it does.  Even in these cases, business volatility and re-use dictates the necessity of the abstraction layer.

    In my current case, the classes generated by EF, exactly match my domain classes except for some stylistic differences.  All that I need to do is tell EF to use the domain classes and account for the name differences.

    At this point, its academic -- I've already added the code to do the object translation.  I just want to know for the future.  It'll be better to maintain one set of classes than two if I don't need to.

    Jason

    Thursday, May 5, 2016 5:00 PM
  • Hi JDWilson,

    >>I'm not.  But understand there is nothing that says it can't.  Its just a mapping issue. 

    You could Configure Domain Classes with DataAnnotation and Fluent API, DataAnnotation is a simple attribute based configuration, which you can apply to your domain classes and its properties. if you don't find some attributes in DataAnnotation, then you have to use Fluent API to configure it.

    For more information, please refer to:

    http://www.entityframeworktutorial.net/code-first/configure-classes-in-code-first.aspx

    http://stackoverflow.com/questions/20944865/repository-pattern-and-mapping-between-domain-models-and-entity-framework

    Best regards,

    Cole Wu


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, May 10, 2016 4:57 AM