Функциональность области ASP.NET 5/MVC 6 в нескольких проектах

Question

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

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

Хотя я думаю, что это выполнимо, исправив все вместе на сервере, должна быть хорошая история разработки и отладки. В идеале основной сайт и дочерний сайт могут быть загружены в Visual Studio для разработки. Кроме того, было бы неплохо иметь возможность выполнять обычное веб-развертывание, не дублируя основные файлы на каждом дочернем сайте.

Как я уже говорил, мы могли бы использовать области, но хотели бы знать, есть ли другие жизнеспособные варианты.

Ответы на вопросы: сайты, вероятно, будут использовать некоторые контексты и модели. Они делятся фактическими объектами в памяти, я так не думаю. У каждого будут свои экземпляры.

Там будет несколько баз данных, разбитых по доменам. Один для основного сайта и еще несколько, по одному на каждый дополнительный сайт. Например, для сайта A может потребоваться доступ к некоторым данным с сайта B. Это будет обрабатываться через уровень данных или обслуживания.

URL-адреса сайта в идеале должны быть следующими: Базовый сайт: http://host/ Суб-сайт A: http://host/a Суб-сайт B: http://host/b

Конкретные вещи, которыми можно поделиться: _layout файлы, css, js, TypeScript, изображения, пакеты bower и т. Д. Может быть аутентификация, конфигурация и т. Д.

Атрибут authorize будет предпочтительным подходом. Единая инфраструктура безопасности, которая ведет себя как единый сайт, будет лучшим вариантом. Не уверен, что это возможно.

Answer 1

Это кажется хорошим вопросом архитектуры. Я не знаю, как правильно ответить на ваш вопрос, потому что я не архитектор, а также потому, что, кажется, вызывает больше вопросов, чем ответов...

Предполагая, что типичное многоуровневое приложение выглядит примерно так:

• Contoso.Core (Библиотека классов)
• Contoso.Data (библиотека классов)
• Contoso.Service (библиотека классов)
• Contoso.Web.Framework (Библиотека классов)
• Contoso.Web (приложение asp.net MVC)

На данный момент я игнорирую тот факт, что вы хотите это в asp.net 5 / MVC 6.

Contoso.Core:

Этот слой будет держать ваш entities/pocos в дополнение ко всему, что может быть использовано в других слоях. Например, это может быть Enums, Extension methods, Interfaces, DTOs, Helpers, так далее...

Contoso.Data:

Этот слой будет где вы будете хранить DbContext (если вы используете EntityFramework) и все DbSets<>, он также будет содержать реализацию ваших репозиториев (в то время как интерфейсы могут жить в Contoso.Core слой... вы поймете, почему позже). Этот слой зависит от Contoso.Core

Contoso.Service:

Этот уровень будет вашим уровнем обслуживания, где вы определяете свои услуги и все бизнес-правила. Методы в этом слое будут возвращать Entities/Pocos или DTO. Службы будут вызывать базу данных через хранилища, если вы используете шаблон проектирования хранилища.

Этот слой зависит от Contoso.Core (для сущностей / pocos / dtos и для интерфейсов репозиториев, так как я предполагаю, что вы будете вводить их). Кроме того, вы также зависите от Contoso.Data слой, где живет реализация ваших репозиториев.

Contoso.Web.Framework:

Этот слой будет зависеть от Contoso.Core, Contoso.Data а также Contoso.Service,

В этом слое вы можете настроить свой IoC Container (Autofac, Unity и т. Д.), Поскольку он может видеть все интерфейсы и их реализацию. Кроме того, вы можете думать об этом слое как "Здесь я настраиваю вещи, которые мое веб-приложение будет использовать / может использовать".

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

Если завтра у вас есть второе веб-приложение Contoso.Web2все, что вам нужно сделать от Contoso.Web2 это добавить ссылку на Contoso.Web.Framework и вы сможете использовать пользовательские расширения HTML, помощники, атрибуты и т. д.

Contoso.Web:

Этот уровень - ваш уровень пользовательского интерфейса / клиента. Этот слой зависит от Contoso.Core (для сущностей / pocos / dtos). Это также зависит от Contoso.Services поскольку контроллеры будут вызывать сервисный уровень, который, в свою очередь, будет возвращать entity / pocos / dtos. Вы бы также зависели от Contoso.Web.Framework так как это где ваши пользовательские расширения HTML живет и что более важно, где ваш IoC container настроен.

Обратите внимание, что этот слой не зависит от Contoso.Data слой. Это потому, что это не нужно. Вы проходите мимо сервисного уровня.

Для записи, вы могли бы даже заменить Contoso.Service Слой с помощью WebAPI (Contoso.API) например, позволяя создавать различные типы приложений (winform, console, mobile и т. д.), все из которых вызывают Contoso.API слой.

Короче говоря... это типичная многоуровневая архитектура, которую вы часто видите в мире MVC.

Так как насчет вашего вопроса о нескольких под сайтах? Где это вписалось бы во все это?

Вот тут и возникает много вопросов...

Будут ли эти дочерние сайты иметь собственный DbContext или использовать тот же, что и основной сайт?

Будут ли эти суб-сайты иметь собственную базу данных или ту же, что и основной сайт? Или даже другое название схемы?

Будут ли эти суб-сайты иметь свои собственные URL-адреса, так как вы, кажется, хотите иметь возможность развертывать их независимо?

Как насчет вещей, которые являются общими для всех этих сайтов?

А как насчет безопасности, авторизации атрибутов и многих других вещей?

Возможно, подход Areas и хранение всего на одном веб-сайте могут быть менее подвержены ошибкам.

Или как насчет NopCommerce и использования подхода плагинов? Будет ли это альтернативой?

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

Answer 2

Вам нужен веб-сайт IIS, настроенный на вашем компьютере разработчика. Вы можете автоматизировать его создание с помощью VS Tasks. У вас также может быть задача построить и опубликовать там свое решение. Это займет некоторое время, но у вас будет то преимущество, что его можно будет повторно использовать на вашем сервере сборки CD/CI при правильной настройке.

Создав основной веб-проект в своем решении, создайте дочерний сайт как новый веб-проект MVC, назвав его так, чтобы это имело смысл. Например, если ваш основной веб-проект называется MySite.Web.Main, вашим дочерним сайтом может быть MySite.Web.MySubsite.

Удалите global.asax и web.config со всех ваших дочерних сайтов, и все. После публикации все ваши дочерние сайты будут полагаться на основной сайт global.asax и web.config. Если вам необходимо добавить изменения конфигурации в основной файл web.config со своих дочерних сайтов, положитесь на задачи преобразования web.config, которые будут запущены после успешного завершения сборки. Вы можете иметь разные файлы преобразования для разных сред.

Помните, что вам необходимо добавить всю эту автоматизацию на ваш сервер сборки CI/CD.

ПРИМЕЧАНИЕ. Когда вы добавляете новую зависимость nuget к своим дочерним проектам, есть вероятность, что она создаст новую веб-конфигурацию. Крайне важно, чтобы все дочерние web.configs были либо удалены, либо изменены таким образом, чтобы их свойство "Build Action" было установлено равным "none", или оно переопределит основную веб-конфигурацию в процессе публикации. Один из способов обойти эту проблему - вместо удаления дочернего web.config вы удаляете его содержимое и устанавливаете "Build Action" на "none", как только вы создаете проект.