Архитектура плагинов ASP.NET: ссылка на другие модули

Question

В настоящее время мы переносим нашу интрасеть ASP в .NET, и мы начали разработку этой интрасети на одном веб-сайте ASP.NET. Это, однако, вызвало некоторые проблемы, связанные с Visual Studio (производительность, время компиляции, ...).

Поскольку наша интрасеть в основном существует из модулей, мы хотим отделить наш проект в подпроектах в Visual Studio (каждый модуль является подпроектом). Это также вызывает некоторые проблемы, потому что модули имеют ссылки друг на друга. Модуль X использует Модуль Y и наоборот ... (круглые зависимости).

Каков наилучший способ разработки такой интрасети?
Я приведу пример, потому что это трудно объяснить.

У нас есть модуль для обслуживания наших сотрудников. У каждого сотрудника есть разные документы (контракт, документы, созданные сотрудником, ...).
Все документы внутри нашей интрасети поддерживаются модулем документов.

сотрудник-модуль должен ссылаться на документ-модуль .
Что делать, если в будущем мне необходимо обратиться к сотруднику-модулю в документ-модуль?

Каков наилучший способ решить эту проблему?

Answer 1

Звучит так, как будто у вас есть две проблемы.

Прежде всего вам необходимо разбить бизнес-ориентированную функциональность системы на сплоченные части; с точки зрения объектно-ориентированное проектирование, есть несколько принципов, которые вы должны использовать, чтобы направлять свое мышление:

• Common Reuse Principle
• Common Closure Principle

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

• Single Responsibility Principle

Не пытайтесь иметь компонент сделать много.

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

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

К счастью, есть уже много существующего материала на плагинов, попробуйте выполнить поиск по тегам, например:

• https://stackoverflow.com/questions/tagged/plugins+.net
• https://stackoverflow.com/questions/tagged/plugins+architecture

Edit:

Активы определяются в другом модуле, чем сотрудники. Но класс Assets определяет свойство AssignedTo, которое имеет тип «Employee». Я ломать голову, как отключить эти два

Там две части к этому, и вы можете захотеть взглянуть на использование как:

• Используя Общую слой, содержащий простые структуры данных что все части системы могут делиться.
• Использование интерфейсов.

Common Layer/Poco в

POCO означает «Объекты Plain Old CLR», идея состоит в том, что ПОКО являются простыми структурами данных, которые можно использовать для обмена информации между слоями - или в вашем случае между модулями, которые должны оставаться слабо связанными. POCO не содержат никакой бизнес-логики. Относитесь к ним так же, как к классам String или DateTime.

Чтобы не ссылаться друг на друга, классы Asset and Employee ссылаются на POCO.

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

Интерфейсы

Это почти то же самое, но вместо ссылки на конкретный объект (как POCO) вы ссылаетесь к интерфейсу. Эти интерфейсы будут определены аналогично описанным выше POCO (общая сборка, без зависимостей).

Затем вы должны использовать Factory, чтобы перейти и загрузить конкретный объект во время выполнения. Это в основном инверсия зависимостей.

Поэтому, вместо ссылок друг на друга, классы Asset and Employee ссылаются на интерфейсы, а конкретные реализации создаются во время выполнения.

Эта статья может быть полезной для обоих вышеуказанных вариантов: An Introduction to Dependency Inversion

Edit:

У меня есть следующий метод GetAsset (интермедиат AssetID); В этом методе заполняется свойство property.AssignedTo (тип IAssignable). Как я могу назначить это правильно?

Это зависит от того, где логика сидит, и как вы хотите, чтобы архитектор вещей.

Если у вас есть бизнес-логика (BL) Layer - это в основном всеобъемлющая модель домена (DM) (из которой оба Asset и Employee были членами), то, скорее всего, Assets и Members будут знать друг о друге и когда вы сделали звонок, чтобы заполнить Asset, и вы, вероятно, получите соответствующие данные Employee. В этом случае BL/DM запрашивает данные - не изолированные классы Asset и Member.

В этом случае ваши «модули» будут другим слоем, который был построен поверх BL/DM, описанного выше.

I вариация на этом заключается в том, что внутри GetAsset() вы получаете только данные о активах, а после этого вы получаете данные о сотрудниках отдельно. Независимо от того, насколько свободно вы будете разбираться в вещах, должно быть некоторая точка, в которой вы определяете связь между Asset и Employee, даже если это просто данные.

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

Answer 2

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

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