Как спроектировать слой бизнес-логики - PullRequest
4 голосов
/ 03 ноября 2010

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

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

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

Как опытный программист, но довольно скромный архитектор, я прошу совета у моих коллег по сообществу.

Редактировать 1:

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

Ответы [ 6 ]

2 голосов
/ 03 ноября 2010

Вид широкого вопроса. Отделите свою БД от своей бизнес-логики (ужасный термин) с помощью технологии ORM (возможно, NHibernate?). Это позволяет вам оставаться в основном на ОО-земле (очевидно), и вы можете в основном игнорировать сторону БД с архитектурной точки зрения.

Продолжая, я считаю, что Domain Driven Design ( DDD ) является наиболее успешным методом разбиения сложной системы на управляемые куски, и хотя это не вызывает уважения, я искренне нахожу UML - особенно действие и класс диаграммы - чтобы быть критически полезными в понимании и коммуникации системного дизайна.

Общий совет: связывайте все, создавайте свои модульные тесты с самого начала и учитесь распознавать и разделять повторно используемые сервисные компоненты, которые могут существовать как подсистемы. FWIW, если кто-то из вас работает над этим, я бы тоже согласился и активно использовал stylecop с самого начала:)

2 голосов
/ 03 ноября 2010

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

Просмотрите образец кода по следующей ссылке:

http://dddpds.codeplex.com/

DDD фокусируется на вашем доменном слое или BLL, если хотите, надеюсь, это поможет.

1 голос
/ 03 ноября 2010

Мы просто говорим об этом с точки зрения архитектуры, и в сущности, это «абстракция, абстракция, абстракция».

Вы можете использовать EBC для проектирования сверху вниз и передачи определений интерфейса командам программистов. Использование подобной методологии (или любого другого метода визуализации) визуализация зависимостей предотвращает дублирование бизнес-логики в любом месте вашего проекта.

0 голосов
/ 03 ноября 2010

Относительно «Правки 1» - я встречался именно с этой проблемой много раз. Я полностью согласен с вами: есть несколько мест, где должна проводиться одна и та же проверка.

Способ, которым я решил это в прошлом, заключается в том, чтобы как-то инкапсулировать правила проверки. Метаданные / XML, отдельные объекты, что угодно. Просто убедитесь, что это то, что можно запросить у бизнес-объектов, взять в другом месте и выполнить там. Таким образом, вы пишете проверочный код один раз, и он может выполняться вашими бизнес-объектами или объектами пользовательского интерфейса или, возможно, даже сторонними потребителями вашего кода.

Существует одно предупреждение: некоторые правила проверки легко инкапсулировать / переносить; "фамилия является обязательным полем", например. Однако некоторые из ваших правил проверки могут быть слишком сложными и включать слишком много объектов, чтобы их можно было легко инкапсулировать или описать в метаданных: «пользователь может включить этот купон только в том случае, если он не является сотрудником, а заказ размещен на выходных дня труда. и у них в корзине есть от 2 до 5 предметов этого конкретного типа, если только у них в корзине нет этих других предметов, но только в том случае, если цвет является одним из цветов нашей «премьеры», кроме бла-бла-бла-бла ... «Вы знаете, какова бизнес-логика! ;)

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

0 голосов
/ 03 ноября 2010

Хм, я могу рассказать вам метод, который мы использовали для довольно большого приложения, ориентированного на базу данных.У нас был один класс, который управлял уровнем данных, как вы предположили, с суффиксом DL.У нас была программа, которая автоматически генерировала этот исходный файл (что было довольно удобно), хотя это также означало, что если мы хотим расширить функциональность, вам необходимо получить класс, поскольку после регенерации исходного кода вы перезаписываете его.

У нас был другой конец файла с OBJ, который просто определял фактическую строку базы данных, обрабатываемую слоем данных.

И, наконец, что не менее важно, с правильно сформированным базовым классом был файл, заканчивающийся на BS (обозначающийбизнес-логика) как единственный файл, который не генерируется, автоматически определяя методы событий, такие как «Новый» и «Сохранить», чтобы при вызове базы выполнялось действие по умолчанию.Следовательно, любое отклонение от нормы может быть обработано в этом файле (включая полное переписывание функциональности по умолчанию, если необходимо).

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

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

0 голосов
/ 03 ноября 2010

Посмотрите в этой теме.Может дать вам некоторые мысли.

Как моя бизнес-логика должна взаимодействовать с моим слоем данных?

Это руководство от Microsoft также может быть полезным.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...