Разделение задач при проектировании многоуровневой архитектуры

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

Я пытаюсь разделить созданный мною проект (изначально не очень удачно спроектированный с архитектурной точки зрения) на разные уровни (каждый в своем собственном проекте):

  • UI
  • Бизнес-объекты
  • Логика / Бизнес
  • DAL

Пользовательский интерфейс должен вызывать только уровень логики, чтобы получить его данные.

Business Objects не должен вызывать или иметь ссылки на что-либо еще, а только способ хранения данных.

Слой Логика / БИЗНЕС должен содержать все методы получения, создания, обновления, удаления (CRUD) объектов в системе и иметь ссылки как на BO, так и на ДАЛ. Он применил бы бизнес-логику к операциям, а затем делегировал бы фактический CRUD DAL.

DAL будет просто выполнять операции CRUD с БД. В нем будет ссылка на BO, поскольку он будет возвращать их для Gets и т. Д.

Мой вопрос: должны ли классы логики вызывать только их эквивалентный класс DAL и вместо этого просто вызывать классы логики? Другими словами, CompanyLogic класс должен вызывать только CompanyDAL класс. Поэтому, если он хотел получить объект A Client по идентификатору, он вызвал бы ClientLogic.GetClientByID(int), а не ClientDAL.GetClientByID(int).

Причина, по которой я подумал, что, возможно, следует оставить на отдельном слое, заключалась в том, что:

  1. Казалось бы, чтобы ослабить связь между проектами

  2. Что насчет логики, если получение клиентского объекта имело некоторую логическую проверку (возможно, не лучший пример, но надеюсь, что он уловит).

РЕДАКТИРОВАТЬ:

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


n-tier-architecture
person Jon    schedule 18.04.2009    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Что ж, вот мои комментарии к вашему дизайну:

  • Логика - плохое имя для того, что по сути является слоем, назначенным абстрактной персистентности. Я бы, вероятно, назвал это «Репозиторий», или «Постоянство», или DAO (объекты доступа к данным), а не «Логика», что неоднозначно и может абсолютно означать что угодно.

  • Если вы действительно хотите отделить свой бизнес-уровень от своего DAL, ваш логический уровень должен принимать только интерфейсы к DAL, а не конкретные классы DAL.

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

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

Удачи!

Обновить

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

Я сторонник простоты и следования YAGNI. Не создавайте интерфейс, пока не будет более двух классов, которые будут реализовывать / уже реализуют этот интерфейс (хотя DAL всегда является исключением из этого правила).

person Jon Limjap    schedule 18.04.2009
comment
полностью согласен с интерфейсами. Я пошел по этому пути и попытался создать фабрику по производству каждого конкретного вида. У меня есть проблемы с моей реализацией, но я сохраню это для другого поста. Хорошо продуманный вопрос о названии "ЛОГИКА", спасибо ... - person Jon; 18.04.2009