Необходима обратная связь по архитектуре n-уровня

Question

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

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

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

Уровень данных (классы DA для SQL Server через Stored Proc)

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

BL имеет ссылку на DA и сущность. Сущность имеет ссылку на DA (DA "не знает" BL или сущности)

Я действительно хочу, чтобы все мои превращения Данных в Сущности происходили внутри БЛ - то есть Бизнес-логики. Тем не менее, я хочу, чтобы сущность могла иметь доступ к BL в случае необходимости - и, таким образом, удалить ссылку сущности на DL.

Итак ...

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

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

public Hashtable[] SubordinateEmployees

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

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

Если так, то мое решение?

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

hashtable = BL.GetSubordinateEmployees(supervisor);

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