Лучшая структура для решения ASP.NET MVC

Я попытался структурировать свой последний крупный MVC-проект после подхода с лучшей практикой, но не совсем понял, что я делаю.

Он имеет проект Data, Business и Web (MVC), но контроллеры содержат большую часть кода, слой данных использует NHibernate и имеет несколько репозиториев, ответственных за слишком много вещей, а бизнес-уровень - это свалка для все, что не входит в два других проекта. Он работает, но я чувствую, что он мог быть настроен лучше - главные вещи, в которых я недоволен, - это контроллеры жира и хранилища.

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

Мои первоначальные надежды заключались в том, что основная часть кода будет поступать в сервисы, и это в сочетании с меньшими репозиториями позволит уменьшить мои контроллеры и уровень данных. Пока что этого не происходит.

Все, что я прочитал, предполагает, что модели просмотра не должны возвращаться с уровня Business и должны быть заполнены на уровне презентации, поэтому на данный момент мой сервисный уровень в основном передает модели с моего уровня данных до презентации который затем делает то, что ему нужно, чтобы подготовить модели просмотра. Таким образом, у меня все еще есть контроллеры жира, а также тонкий бизнес и уровень данных.

Мой уровень представления также знает как мой бизнес, так и уровень данных, но я думал, что частью этого разделения было сокращение связи?

Неужели я все это не так? Должен ли я перестать пытаться слепо следовать тому, что я читаю в Интернете, и просто подготовить модели просмотра в бизнес-слое, чтобы я мог переместить основную часть моего кода там? Должен ли я просто вернуться к классическому ASP?:)

Ответ 1

основное руководство, которое я использую при создании структуры проекта, - это обеспечить, чтобы я мог добавить некоторые атрибуты operationcontract на уровень бизнес-логики, а затем разместить его как службу wcf.

Если я могу это сделать, это означает, что уровень бизнес-логики изолировал мой уровень данных и взаимодействует с его клиентом только путем передачи простых структур и объектов. datalayer полностью скрыт.

Итак, моя обычная структура выглядит так:

Solution
    Business.Contracts (interfaces for bll layer in here)
    Business.Logic     (concrete implementations of contracts in here)
    Business.Entities  (Pocos that bll uses)
    Data.Contracts     (interfaces for dal)
    Data.Sql           (Concrete Sql implementation of contracts)
    Common.Enums       (Enums needed by all projects)
    FrontEnd           (Main mvc app)

Итак, в этой структуре мой проект mvc только когда-либо имеет дело с пространством имен и общим пространством имен.

При взаимодействии с сущностями, однако, я стараюсь использовать свои собственные модели в проекте mvc, чтобы я мог добавлять аннотации и специальные функции переднего плана, а затем я предоставляю неявные преобразования для этих моделей, которые могут быть взаимозаменяемы с хозяйствующих субъектов.

НТН