Clean solution (project) structure with EF, Repositories, Entities

Question

I like to keep the structure of the project as clean as possible. Sample:

--BlogApp.sln
  --BlogApp.Data
      BlogModel.edmx (the EF mappings)
      Post.cs (I end up having partial classes in here with attributes)
  --BlogApp.Domain
    --Entities
        Post.cs (I would like to have my POCOs here with all its additional logic)
    --Repositories
        PostsRepository.cs
  --BlogApp.Ui
      (standard MVC structure)

I end up with mess when using EF as my ORM. Could anybody suggest some "clean" way to structure the project? Or maybe you could suggest some standard project structure that is most commonly used.

I'm unsure what you mean. When you update your EF4 bindings, do it not regenerate the model? — Phil C, Mar 12 '11 at 14:48
What I mean is that I want to have very clear separation of entities from data source. Just Like with nHibernat mappings. — Naz, Mar 12 '11 at 15:19
Oh, separation of concerns - I posted something on this earlier in the week with MVC2 in mind. I'll dig it out later if no-one answers. — Phil C, Mar 12 '11 at 15:21
you could use my "live demo" from here http://awesome.codeplex.com/, it uses DDD — Omu, Mar 12 '11 at 21:47

score 23 · Accepted Answer · answered Mar 12 '11 at 16:59

My preferred structure is:

Solution
  -- 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

where do your unit/UI/integration tests go? I hope your not saying your solution doesn't need them :(. — stevebot, Mar 26 '13 at 21:44
i find the Entities part confusing. Could you expand on what you mean by `T4 template + partial classes + custom enums` ? — Rafael Herscovici, Jun 27 '15 at 08:16

Kon · Answer 2 · 2011-03-12T15:24:03.980

Check out this write up on T4 Templates and the Entity Framework. You can write in custom attributes for entity properties generated via EF. I've done this several times, and after figuring out how to do it, it now saves a lot of time. I've tried using partial classes before as you mention, but my EF-generated class ends up overwriting the other with the custom attributes. Perhaps I was doing something wrong, but in any case, I now prefer the T4 template solution because it seems cleaner to me - minimizing on number of classes within a project.

Also, when you update your EF model from DB and the class is regenerated, your custom attributes are still in place. ftw!

ADDED: By the way, we typically define our model objects within the Data layer to have them mapped/populated by EF's entities. Or (even simpler) use the EF-generated entities all the way through to the UI layer without custom defined POCOs.

Clean solution (project) structure with EF, Repositories, Entities

2 Answers2

Linked