Существует множество различных подходов и стратегий для решения этих типов проблем, в зависимости от ваших конкретных требований. Фактически, существуют целые фреймворки, которые были написаны для помощи в упаковке, регистрации и внедрении плагина в. NET (см., Например, Managed Extensibility Framework ).
Тем не менее, я может помочь вам направить вас в направлении, которое может помочь вам решить эти проблемы.
Распределение MVC приложений в виде модулей
Прежде всего, я рассмотрю Библиотеки классов Razor . Они были введены в ASP. NET Core 2.1 и расширены в ASP. NET Core 3.0 . Они позволяют создавать сборки, содержащие модели, представления и контроллеры (в ASP. NET Core 2.1 ), а также ресурсы stati c (например, сценарии, изображения и & *). 1094 *.) (В ASP. NET Core 3.0 ). Они могут даже быть упакованы и распространены как NuGet пакеты, если вам нужно распространять их для использования в нескольких проектах.
Примечание: Технически, если вы нужно, есть способы встраивания stati c активов в ASP. NET Core 2.1 библиотеки классов Razor, но по умолчанию оно не включено, имеет некоторые ограничения и формат изменился в ASP. NET Core 3.0 .
Ссылка на общее содержимое c из модулей
Ваша Библиотека классов Razor может вызывать любые stati c ресурсы или представления из вашего основного приложения - хотя это не очень хорошая практика, так как это означает установление жестко закодированных зависимостей от ресурсов вне конкретного проекта, что затрудняет изменение местоположения этих файлов или проверьте, указывают ли они на правильное местоположение. Лучшим вариантом может быть регистрация (расположение) этих ресурсов с помощью объекта конфигурации и использование этого объекта для ссылки на это расположение.
Ссылка на библиотеки общих классов из модулей
Несмотря на это, по умолчанию ваши библиотеки классов Razor не смогут вызывать классы, которые содержатся в вашем основном приложении. Чтобы обойти это, используйте внедрение зависимостей , как рекомендует @ jonny-lin в комментариях. Основная идея c заключается в том, что вы устанавливаете sh центральную библиотеку классов, от которой зависят ваши Razor Class Libraries и ваше основное приложение, от которого определяются интерфейсы для каждой службы. Ваше основное приложение (или его зависимости) устанавливает sh конкретные версии этих сервисов. Ваши модули, в свою очередь, зависят от этих интерфейсов. Затем вы можете внедрить конкретную реализацию этих сервисов в ваши модули.
Примечание: Существует ряд стратегий для внедрения внедрения зависимости, вручную сборка вашего графа зависимостей через IControllerActivator с использованием контейнера ввода зависимостей , такого как встроенный в ASP. NET Core . В любом случае, в приложении MVC общая стратегия заключается в том, чтобы контроллер принимал необходимые интерфейсы через конструктор, а затем вводил конкретные реализации через основное приложение.
Настройка модулей в основном приложении
Наконец, вам нужно установить sh способ регистрации ваших модулей в вашем основном приложении. Если он просто определяет повторно используемые библиотеки классов, это может быть так же просто, как ссылаться на сборку и затем вызывать ее классы. Если оно содержит базовое c MVC приложение, оно может быть уже доступно, в зависимости от того, как вы обрабатываете свою маршрутизацию, но во многих случаях вам потребуется настроить новый маршрут для области. В более сложном сценарии, вероятно, имеет смысл создать в ваших модулях методы расширения, которые можно вызывать из вашего Startup класса для обработки регистрации служб и маршрутов.
Автоматически обнаружение модулей в вашем основном приложении
Конечно, если вы хотите, чтобы модули автоматически обнаруживались и конфигурировались основным приложением, это немного сложнее. В этом случае вы, вероятно, в конечном итоге создадите класс конфигурации в каждом модуле, который реализует предопределенный интерфейс - например, IModuleConfiguration. Ваше основное приложение будет затем использовать отражение, чтобы найти все классы во всех загруженных сборках, которые реализуют IModuleConfiguration, и вызвать метод конфигурации для каждой из них. Этот метод почти наверняка должен иметь некоторую форму внедрения зависимостей, чтобы зависимости, на которые опирается каждый модуль, могли быть зарегистрированы как часть конфигурации. Одна библиотека, которая может помочь с такими функциями, это Microsoft.Composition, который является частичным портом от Managed Extensibility Framework до ASP. NET Core. Однако это может быть довольно сложно довольно быстро.
Очевидно, что реализация всего этого потенциально очень сложна и почти наверняка вызовет множество дополнительных вопросов, в зависимости от того, насколько вы знакомы с этими подходами. Моя цель в этом ответе - не рассмотреть все эти возможности, а изложить общую стратегию решения проблемы такого типа.
Надеюсь, это поможет!