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

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开发者_JAVA百科 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.

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.