Структура чистого решения (проекта) с EF, репозиториями, сущностями

Мне нравится, чтобы структура проекта была максимально чистой. Пример: 

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

Я заканчиваю с беспорядком, когда использую EF в качестве моего ORM. Может ли кто-нибудь предложить какой-то "чистый" способ структурировать проект? Или, может быть, вы могли бы предложить какую-то стандартную структуру проекта, которая наиболее часто используется.

2 7
asp.net-mvc entity-framework projects-and-solutions project-structure

2 ответа:

Моя предпочтительная структура: 

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
16

Проверьте эту запись на шаблонах T4 и Entity Framework. Вы можете записать пользовательские атрибуты для свойств сущностей, созданных с помощью EF. Я делал это несколько раз, и после того, как выяснил, как это сделать, теперь это экономит много времени. Я уже пробовал использовать частичные классы, как вы упомянули, но мой EF-сгенерированный класс в конечном итоге перезаписывает другой с помощью пользовательских атрибутов. Возможно, я делал что-то не так, но в любом случае, теперь я предпочитаю шаблонное решение T4, потому что мне кажется чище-минимизация количества классов внутри проекта.

Кроме того, при обновлении модели EF из БД и регенерации класса пользовательские атрибуты остаются на месте. США.

Добавлено : Кстати, мы обычно определяем объекты нашей модели в слое данных, чтобы они отображались / заполнялись сущностями EF. Или (еще проще) используйте EF-генерируемые сущности вплоть до уровня пользовательского интерфейса без пользовательских POCOs.

2