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

Question

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

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

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

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

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

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

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

Answer 1

Главное руководство, которое я использую при создании структуры проекта, заключается в том, чтобы я мог добавить некоторые атрибуты contractcontract для уровня бизнес-логики, а затем разместить его как службу 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, чтобы позволить мне добавлять аннотации и специальные функции переднего конца, а затем я предоставляю неявные преобразования для этих моделей, чтобы они могли быть взаимозаменяемы с хозяйствующих субъектов.

НТН