Structured solution (project) using EF, Repositories, and Entities entity-framework projects-and-solutions project-structure


I try to keep the project's organizational structure as simple as feasible. Sample:

      BlogModel.edmx (the EF mappings)
      Post.cs (I end up having partial classes in here with attributes)
        Post.cs (I would like to have my POCOs here with all its additional logic)
      (standard MVC structure)

When I use EF as my ORM, I get a mess. Could somebody provide a "clean" suggestion for how to organize the project? Or maybe you could offer a typical project structure that is used most often.

3/12/2011 3:44:31 PM

Accepted Answer

My favorite format is:

  -- Common
       - Shared features used accross all layers
       - You can also place interfaces for repositories and uow here
  -- Entities - shared among DataAccess, Business (and UI in small projects)
       - T4 template + partial classes + custom enums  
       - partial classes can contain methods with domain logic => domain objects 
  -- DataAccess - all EF dependent code here
       - EDMX or code first mapping
       - Repositories
       - UnitOfWork
  -- Business - not every project needs this assembly
       - Business services 
       - Logic like workflows
       - DTOs exposed to UI
  -- UI
       - Controllers
       - Views
       - ViewModels
3/12/2011 4:59:55 PM

Popular Answer

See this article about Using the Entity Framework with T4 Templates. For entity properties produced by EF, you may enter custom attributes. I've done this a few times, and now that I know how to do it, it really does save a ton of time. As you note, I've tried utilizing partial classes previously, however the custom characteristics from my EF-generated class always end up replacing the other class. In any event, I now prefer the T4 template option since it appears clearer to me and reduces the amount of classes inside a project, but maybe I was doing something incorrectly.

Additionally, your custom attributes are preserved when you update your EF model from the database and the class is produced. ftw!

By the way, we often create our model objects inside the Data layer so that EF's entities may map to and fill them. Or, (even more simply), utilize the EF-generated entities up till the UI layer without using specially specified POCOs.

Related Questions


Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow