Простой совет по архитектуре приложения

Question

Я пытаюсь создать небольшое демонстрационное веб-приложение, которое будет слабо связанным, хорошо тестируемым, с хорошим чистым кодом и т. Д. Короче, я экспериментирую с правильными действиями. ;)

В настоящее время в моем решении Wolfie есть три проекта:

• Wolfie.Core - содержит бизнес-объекты
• Wolfie.Data - содержит код доступа к данным, ссылки на ядро.
• Wolfie.Web - будет веб-сайт Нэнси.

В его нынешнем виде Ядро ничего не знает ни о каких других проектах. Данные должны ссылаться на ядро, так как ядро ​​имеет типы, которые будут возвращать данные. Поэтому в этот момент я осознаю, что Web должен ссылаться как на ядро, так и на данные, чтобы иметь возможность работать, поскольку тип сущности находится в ядре, а вызовы базы данных - в данных.

Все классы репозитория в Data имеют интерфейсы, так что репозитории можно макетировать для тестирования.

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

Правильно ли ссылаться на оба проекта из Интернета? или потребуется другой проект между Web и остальными, чтобы Web ссылался только на одно место и не отвечал за вызов методов Data и т. д.

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

Надеюсь, у меня есть некоторый смысл, и я с нетерпением жду некоторых полезных ответов.

Answer 1

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

В этом приложении бизнес-логика домена была изолирована сама по себе "Сборка "домен" (ваша сборка "Core") и ничего не ссылается за пределами .NET Framework.Для подключения к внешним бизнес-компонентам, таким как база данных и другие веб-сервисы, существовала сборка «Инфраструктура» (ваша сборка «Данные»).Ключом для этого приложения является то, что каждая реализация в сборке инфраструктуры была сопряжена с сборкой домена и возвращала объекты сборки домена (как вы описали).Это, конечно, требовало ссылки из инфраструктуры на домен.

Чтобы связать все это вместе, сборка "WebApp" (ваша сборка "Web") ссылалась на сборки домена и инфраструктуры и использовала контейнер IoC дляразрешить все зависимости приложения.Когда запросы поступают в WebApp, он разрешает соответствующий контракт «Домен» для обслуживания запроса, который запускает цепочку вызовов для разрешения IoC.Помимо регистрации реализаций инфраструктуры, сборка WebApp не заботится о существовании сборки инфраструктуры.

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

• В бизнес-домене нет внешних ссылок.
• Приложение бизнес-домена полностью не зависит от веб-интерфейса и базы данных.

Это обеспечивает лот тестируемости для вашей бизнес-области и лот гибкости в отношении того, как интерфейс взаимодействует с вашим доменом.Фактически, эта гибкость равна , что делает ее такой тестируемой.Эта гибкость имеет и другие преимущества.Например, если ваш бизнес-домен изолирован, вы можете легко кодировать новый интерфейс CLI или WPF, подключенный к интерфейсу файловой системы, не изменяя код бизнес-домена, если вы хотите развернуть и запустить клиентлокально на машине.

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

Answer 2

Я не думаю, что с этими двумя ссылками что-то не так.

Но я бы подумал, что такое «Ядро». Это логика вашего домена? Если так, я не уверен, что у меня была бы ситуация, когда ваша сборка доступа к данным знает о логике вашего домена, а ваш уровень GUI знает об обоих.

Если «Ядро» является доменной логикой, вы можете поместить в нее классы (например, Шаблон IRepository ), которые знают о сборке «Данные». Ваша веб-сборка будет знать о «ядре», но не о «данных».

Чтобы упростить эту договоренность, вы можете создать четвертую сборку под названием «DataTransfer» и определить некоторые объекты (или, еще лучше, интерфейсы), о которых «Core», «Data» и «Web» знают и используют для связи с друг друга. На самом деле, если вы действительно хотите отсоединиться, структурирование вещей с помощью сборки «Типы», содержащей интерфейсы, может на самом деле сделать так, чтобы ни одна из трех ваших исходных сборок не знала друг о друге.

Но тогда, если «Ядро» - это на самом деле библиотека, а не логика вашего домена, возможно, имеет смысл перейти к вашей текущей структуре и, возможно, позже пересмотреть ее, если вы добавите достаточно функциональности, чтобы начать использовать больше сборок / слоев.

Изменить: Чтобы помочь визуализировать, что я имею в виду, я говорю о многоуровневой ситуации:

Web
 | 
 v
Core
 |
 v
DataAccess

вместо:

Web
 |  \
 v   \
Core  |
 ^    |
 |    v
DataAccess

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

Answer 3

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

Answer 4

Я думаю, что это имеет смысл. Пока вы отделяете Web от бизнес-уровня, это позволяет вам легче тестировать бизнес-логику, а также предоставлять бизнес-уровень другими способами (например, Web-сервисами) и т. Д.

Answer 5

Архитектура 1. Данные 2. Бизнес-логика 3. Клиент. Данные есть данные. Бизнес логика работает на данных. Клиент подключается к бизнес-логике, такой как data-> business logic-> client. Клиент не подключается к данным напрямую. 3 слоя. клиент логики данных.