locked
Splitting Entity Framework Model classes into separate projects RRS feed

  • Question

  • Hi,

    I'm trying to follow this article and some more besides: http://nullablecode.com/2013/09/splitting-entity-framework-model-classes-separate-projects/

    As soon as I delete the *.tt file from my DAL project and edited the Custom Tool Namespace of the Context.tt file of the same project I can no longer reference the entities.

    Can't see where I am going wrong.

    Tuesday, July 1, 2014 11:20 AM

Answers

  • I can say that I wouldn't even be bothered with that link. If one wants to do what you are trying to do, then one would just make a simple classlib project called Entities. In the Entities project is where all the DTO(s) for the EF Entites would be kept. All projects in the solution would have project reference to the Entities project. I wouldn't be messeing around with any *.tt files or anything like that and just leave it alone.

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

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

    The Entities project and the DTO(s) in the project are an abstraction layer away from the EF model so no project deals with the EF model entities/objects directly  other than the project that does CRUD  operations with the model by mapping data between a EF entity and DTO or vice versa.

    Tuesday, July 1, 2014 2:10 PM
  • Hi just downloaded Entity Framework DTO doesn't appear to be a VS2013 version as of yet. So I'll create the DTO's in VC2012 and do the rest in VS2013 afterwards.

    Yeah, that's what I did was goback to VS2010 to use Entity2DTO in that version to generate the DTO(s). Then I just copied them over to the VS2013 project. They are just DTO(s) that will not present a problem until the guy makes a version of Entity2DTO as a VS2013 addin.

    Sounds like a safer way to go as opposed to  what I have tried up until now.

    Yep....

    One question are the DTO's updatable at a later stage?

    All one has to do is point the generator back to the EF model to regenerate DTO(s). The generator allows one to select the DTO to be generated by indivdual slections. You can also use a partial class like DtoCustomerPartial.cs to extend the functionaly of the generated DtoCustomer.cs, which is nice too.

    If you need to map the DTO to a custom object or or vice versa, like you had to map from DTO to Model Object up at the MVC Model in an MVC solution, then you can use something like Automapper.

    http://www.codeproject.com/Articles/61629/AutoMapper

    Down at the layer where CRUD was being done, then I would let Entity2DTO do its mapping in both directions.

    Tuesday, July 1, 2014 3:55 PM

All replies

  • I can say that I wouldn't even be bothered with that link. If one wants to do what you are trying to do, then one would just make a simple classlib project called Entities. In the Entities project is where all the DTO(s) for the EF Entites would be kept. All projects in the solution would have project reference to the Entities project. I wouldn't be messeing around with any *.tt files or anything like that and just leave it alone.

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

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

    The Entities project and the DTO(s) in the project are an abstraction layer away from the EF model so no project deals with the EF model entities/objects directly  other than the project that does CRUD  operations with the model by mapping data between a EF entity and DTO or vice versa.

    Tuesday, July 1, 2014 2:10 PM
  • Hi just downloaded Entity Framework DTO doesn't appear to be a VS2013 version as of yet. So I'll create the DTO's in VC2012 and do the rest in VS2013 afterwards.

    Sounds like a safer way to go as opposed to  what I have tried up until now.

    One question are the DTO's updatable at a later stage?

    Thanks for your help again :)

    Tuesday, July 1, 2014 3:00 PM
  • Hi just downloaded Entity Framework DTO doesn't appear to be a VS2013 version as of yet. So I'll create the DTO's in VC2012 and do the rest in VS2013 afterwards.

    Yeah, that's what I did was goback to VS2010 to use Entity2DTO in that version to generate the DTO(s). Then I just copied them over to the VS2013 project. They are just DTO(s) that will not present a problem until the guy makes a version of Entity2DTO as a VS2013 addin.

    Sounds like a safer way to go as opposed to  what I have tried up until now.

    Yep....

    One question are the DTO's updatable at a later stage?

    All one has to do is point the generator back to the EF model to regenerate DTO(s). The generator allows one to select the DTO to be generated by indivdual slections. You can also use a partial class like DtoCustomerPartial.cs to extend the functionaly of the generated DtoCustomer.cs, which is nice too.

    If you need to map the DTO to a custom object or or vice versa, like you had to map from DTO to Model Object up at the MVC Model in an MVC solution, then you can use something like Automapper.

    http://www.codeproject.com/Articles/61629/AutoMapper

    Down at the layer where CRUD was being done, then I would let Entity2DTO do its mapping in both directions.

    Tuesday, July 1, 2014 3:55 PM
  • Many thanks for your help, really appreciated.

    If you have time (I will try and find the answer myself in the meantime) what is the cleanest way to convert/cast the entity object to its DTO equivalent?

    Example I've seen so far are things like:

    public static FamilyDTO ToDTO(this Family entity)
    {
        if (entity == null) return null;
    
        var dto = new FamilyDTO();
    
        dto.FamilyCode = entity.FamilyCode;
        dto.FamilyName = entity.FamilyName;
        dto.CreateDatetime = entity.CreateDatetime;
        dto.Updates_ID = entity.Updates.Select(p => p.ID).ToList();
    
        entity.OnDTO(dto);
    
        return dto;
    }

    Is there not a cleaner less verbose way of doing this approach where each property has to be set in the DTO? I thought maybe reflection might be a candidate possibly.

    Thanks again :)

    Wednesday, July 2, 2014 7:31 AM
  • Is there not a cleaner less verbose way of doing this approach where each property has to be set in the DTO? I thought maybe reflection might be a candidate possibly.

    You have 3 choices and are the following:

    1) You can make methods that do the mapping between the two objects. Sometimes you have to do checks on properties for null values to take the appropriate code path to populate data between the objects.

    2) If using Entity-2-DTO, then you can use the mapping logic that Entity-2-DTO provides.

    3) You can use a 3rd party solution like Automapper, which is free that can be installed using Nuget.

    4) You can go cowboy and try to do it with Reflection, which would be the last approach I would take.  

    Wednesday, July 2, 2014 10:52 AM