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