n-Tier Architecture Обратная связь Нужно

Question

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

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

Business Layer (старомодный объект классы и слой BL)

уровня данных (классы DA к SQL Server через ХП)

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

BL имеет ссылку на DA и сущность. предприятия имеет ссылку на DA (ПДР является «знать» о BL или Entity)

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

Итак ...

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

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

public Hashtable[] SubordinateEmployees 

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

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

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

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

Answer 1

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

hashtable = BL.GetSubordinateEmployees(supervisor); 

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

Answer 2

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

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

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

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

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

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

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