Какова наилучшая практика для архитектуры приложений уровня предприятия с использованием MVC5?

Ответ 1

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

• Прежде всего, важно отметить, что при разработке программного обеспечения процесс не имеет ничего общего с правильным и неправильным. До тех пор, пока подход работает для вашего проекта и подходит хорошо, это right, и если это не так, это wrong. В программном обеспечении нет жестких принципов дизайн. Есть Project needs and specifications. Но в целом, он принят с использованием Design Patterns and Principles делает выполните проект robust, reliable и easy to maintain и сделайте ваш код loosely coupled and highly cohesive.
• Вся история Software Design and Architecture о том, как вы могли бы легко управлять своим проектом и как вы могли бы поддерживать свой будущие изменения. Подумайте, какой подход дает вам лучший ответ на их. Это будет лучше для вас. Не думайте слишком много о Professionalism!. Ваш проект растет со временем и становится более зрелым. Так что просто подумайте о своем проекте!
• В качестве первого шага и для архитектуры приложений уровня предприятия, всегда старайтесь следовать Separation of Concerns или SoC. Это означает, что вы должны иметь разные уровни для разных уровней вашего проекта. Это настоятельно рекомендуется использовать другой проект в вашем решение для Data Access Layer, Domain Entities, Business Layer и Presentation Layer. В проекте MVC5 лучше использовать Class Library Project для Data Access Layer, Domain Entities, Business Layer и проект MVC для Presentation Layer.
• Data Access Layer - это проект, который сталкивается с взаимодействием базы данных и базы данных. В этом проекте вы могли бы использовать все Entity Framework или аналогичные объекты. Разделение слоя для уровня базы данных означает, что при изменении хранилища данных проекта вам нужно изменить только этот проект и некоторые незначительные изменения на вашем Business Layer. Все остальные проекты в вашем решении остаются нетронутыми. Таким образом, вы можете легко перейти от MS Sql к Oracle или от Entity Framework до NHibernate.
• Domain Entities - это проект, который я использую для определения всего моего решения интерфейсы уровня, классы, перечисления и переменные. Этот проект сохраняет целостность во всем моем решении на моих классах и моих методах. мой все классы в целом решении наследуются от интерфейсов в этом проект. Поэтому у меня есть одно место, чтобы изменить мои классы или глобальные переменные, а это означает easy to maintain для будущего в моем решении и легко понять для недавно присоединившихся разработчиков к проекту.
• Business Layer - это место, в которое я положил всю свою бизнес-логику, включая Business Entities и Business Services. Вся идея о этот слой имеет одно место для хранения всех ваших бизнес-методов и взаимодействия. Все вычисления, модификация объекта и вся логика о данных, включая сохранение, извлечение, изменение и т.д., должны происходят в этом разделе. Имея этот слой в своем проекте, вы могут иметь разных потребителей одновременно, например один native MVC и один Web API. Или вы могли бы предоставить разные питание на основе различных бизнес-услуг потребителей технические характеристики. Настоятельно рекомендуется избегать бизнес-логики в секции контроллера уровня MVC. Наличие бизнес-логика внутри контроллеров означает, что вы используете презентацию как уровень бизнес-логики, и он нарушает Separation of Concerns. Тогда это не будет легко изменить с одного презентационного слоя на другого или с другим типом потребителей для вашего решение. Лучше держать секцию контроллера в MVC такой же тонкой, как возможное. Контроллеры должны иметь только логику и методы непосредственно связанный с View Models. Для получения дополнительной информации о View Models обратитесь к разделу 7. Помните, что лучше имеют разные классы Business Services, основанные на вашем решении объектов или Business Entities.
• Presentation Layer в MVC-решении будет проект MVC. Но решение может иметь другой тип или более одного уровня представления для разных потребителей или технологий. Например, вы могли бы один слой MVC и один Web API в одном решении. Как правило, использование Уровень презентации, чтобы сохранить в нем всю логику представления. Логика представления не должна иметь ничего, что связано с бизнес-логикой или логики данных. Итак, вопрос в том, что такое Presentation logic? Presentation logic - это логика, связанная с моделями просмотра. Просмотр моделей объекты, настроенные для просмотров или страниц. В большинстве случаев бизнес объекты не подходят для использования в представлениях. С другой стороны, представления представления обычно нуждаются в некоторой логике проверки или логика представления, например, отображаемое имя отличается от оригинала имена объектов. В этих случаях лучше вести логику представления разделены, чем бизнес-логика, чтобы упростить изменение презентации логики или бизнес-логики самостоятельно и даже легко переключаться уровень представления для дизайна пользовательского интерфейса или меняющегося бизнеса логика для обеспечения большей функциональности, не опасаясь прерывания с логикой представления. В случае использования проекта MVC в качестве уровень представления для решения, все модели просмотра должны быть Models в проекте MVC, и вся логика представления должна быть размещен в разделе Controllers проекта.
• Последнее, что нужно сказать для каждого многоуровневого решения, вам нужно рамки для сопоставления объектов с объектами, например, для преобразования бизнес-объект для просмотра модели. Есть несколько инструментов для этого такие как AutoMapper, BLToolkit и EmitMapper.

Последнее слово: прокомментируйте и оцените question и мой answer, чтобы сделать его лучше!

Ответ 2

Взгляните на Contoso University. Отличный пример приложения уровня предприятия.

Пример демонстрации веб-приложений