Требуется обратная связь по многоуровневой архитектуре

Question

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

Презентация (Интернет)

Бизнес-уровень (старомодные классы сущностей и уровень BL)

Уровень данных (классы DA для SQL Server через хранимую процедуру)

Мой вопрос в первую очередь касается бизнес-уровня.Прямо сейчас у меня есть пространство имен Entity и пространство имен BusinessLogic.

BL имеет ссылку на DA и Entity.У субъекта есть ссылка на DA (DA «не знает» BL или сущности)

Я действительно хочу, чтобы вся моя работа по превращению данных в сущности происходила внутри BL — то есть бизнес-логики.Однако я хочу, чтобы сущность могла получить доступ к BL, если это необходимо, и, таким образом, удалить ссылку сущности на DL.

Так...

Является ли «неправильным» размещение объектов BL и Entity в одном пространстве имен, чтобы они могли работать вместе?

По сути, я пытаюсь создать объект сущности, такой как Сотрудник (классический пример, а?), и чтобы у Сотрудника был

public Hashtable[] SubordinateEmployees

свойство, которое возвращает хеш-таблицу других объектов «Сотрудник», которые подчиняются этому сотруднику.Но я не хочу загружать его, пока он не понадобится.Таким образом, для большинства сотрудников свойство никогда не получит доступа, но когда это произойдет, оно самозагружается с помощью вызова BL, который вызывает DA.

Имеет ли вопрос смысл?

Если да, то подходит ли мое решение?

Большое спасибо заранее!

Answer 1

Обычный способ справиться с ситуацией, которую представляет ваш пример, — это фасады.Вместо того, чтобы пытаться получить подчиненных сотрудников из объекта «Сотрудник», вы используете для этого вызов бизнес-логики.

hashtable = BL.GetSubordinateEmployees(supervisor);

Таким образом, у вас есть единая точка доступа к подчиненным, и только одна вещь (BL) имеет доступ к уровню данных и создает сущности.

Answer 2

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

у вас есть доступ к данным (sql-сервер, mysql, плоские XML-файлы и т. д.) все это должно быть абстрагировано, ничто другое в вашем приложении не должно заботиться или знать, как вы получаете свои данные, только то, что оно дозирует, если что-то еще знает как вы получаете свои данные, у вас есть нарушение уровня.если DAL дозирует что-то другое, то получит данные, у вас есть нарушение уровня.Затем вы реализуете интерфейс доступа к данным, что-то вроде IDAL, который использует ваш бизнес-уровень. Это очень важно для того, чтобы сделать ваш код тестируемым, заставляя вас разделять ваши уровни.

Ваши объекты данных могут быть помещены в пространство имен DAL или предоставлены им самостоятельно, предоставив им собственное разделение.Сущности данных являются глупыми объектами и должны содержать очень мало логики или вообще ее не содержать и осознают только себя и имеющиеся у них данные. ОНИ НЕ СОДЕРЖАТ БИЗНЕС-ЛОГИКУ!, ЛОКИК ДОСТУПА К ДАННЫМ ИЛИ ЛОГИКУ ПИ.если да, то у вас есть нарушение слоя.Единственная функция объекта данных — хранить данные и передавать их с одного уровня на другой.

Бизнес-уровень реализует интерфейс доступа к данным, такой как IDAL, о котором мы говорили, прежде чем вы сможете создать его экземпляр с помощью фабрики, IOC-контейнера или чего-либо еще, если не удается определить конкретный тип, но добавьте свойство установки, чтобы его можно было изменить для тестирования.Бизнес-уровень обрабатывает только бизнес-логику, он не знает и не заботится о том, откуда пришли данные или куда они направляются, он заботится только о манипулировании данными для соответствия бизнес-правилам, это может включать проверку даты, фильтрацию (частично это сообщив DAL, какие данные ему нужны, пусть DAL сам разберется, как их получить).По сути, BIZ обрабатывает всю логику, не связанную с пользовательским интерфейсом или поиском данных.По той же причине, как и DAL, Biz должен реализовать интерфейс.

Уровень пользовательского интерфейса обращается к уровню Biz так же, как уровень Biz обращается к DAL, по той же причине.Все, что заботит уровень пользовательского интерфейса, — это отображение данных и получение данных от пользователя.Уровень IU не должен ничего знать о бизнес-правилах, за возможным исключением проверки данных, необходимой для заполнения объектов данных.

Преимущество этой архитектуры заключается в том, что она обеспечивает разделение задач, что упрощает тестирование, делает ее более гибкой и простой в обслуживании.Сегодня вы создаете веб-сайт, но завтра вы захотите позволить другим интегрироваться через веб-сервис. Все, что вам нужно сделать, это создать веб-сервис, реализующий интерфейс IBIZ, и все готово, когда вам нужно исправить ошибку в BIZ. уровне, он уже исправлен как на вашем веб-сайте, так и на веб-сервисе.

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