Как вы держите свои бизнес-правила СУХОЙ?

В идеальном приложении каждое бизнес-правило будет существовать только один раз.

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

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

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

Попытка принудительно выполнить проверки в одном месте непросто в свете противоречивых соображений - оставайтесь СУХОЙ, держите базу данных в крепости и обеспечивайте хороший пользовательский интерфейс. У меня есть некоторая идея для преодоления этой проблемы, но я думаю, что есть лучше.

Можно ли сбалансировать эти конфликтующие проблемы в сухом образе?

Ответ 1

Любой, кто не применяет требуемые бизнес-правила в базе данных, где они находятся, будет иметь плохие данные, просто так. Целостность данных - это задание базы данных. Базы данных затронуты гораздо большим количеством источников, чем приложение, и включение необходимых правил в приложение только недальновидно. Если вы сделаете это, вы получите плохие данные от импорта, из других приложений, когда они подключатся, от специальных запросов, чтобы исправить большие объемы данных (думаю, что все цены повышаются на 10%) и т.д. Глубоко в крайнем случае обеспечить соблюдение правил только через приложение. Но опять же, я человек, который должен исправить плохие данные, попадающие в плохо разработанные базы данных, где разработчики приложений считают, что они должны делать что-то только в приложении.

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

Ответ 2

Таким образом, чистое разделение проблем, когда вся бизнес-логика существует в одном ядре, - утопическая фантазия, которая трудно поддерживать

Не могу понять, почему.

обрабатывать всю бизнес-логику в отдельном ярусе (в Rails модели будут содержать "большинство" этого)

Правильно. Django также делает это.

некоторые бизнес-логики в конечном итоге разливаются в другие места (в Rails он может перетекать в контроллеры

Не совсем. Бизнес-логика может и должна быть в модельном ярусе. Некоторые из них будут закодированы как методы классов, библиотек и других пакетов логики, которые можно использовать в других местах. Django делает это с объектами Form, которые проверяют ввод. Они взяты из модели, но используются как часть интерфейсного HTML, так и для любых объемных нагрузок.

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

Используйте слой ORM для генерации SQL из модели. Все в одном месте.

[база данных], построенная на ограничениях, которые вызывают отклонение плохих данных

Я думаю, что неправильно прочитал сообщение База данных как крепость. В нем говорится "Твердая модель данных", "отклонять данные, которые не принадлежат, и предотвращать отношения, которые не имеют смысла". Это простая декларативная ссылочная целостность.

Слой ORM может генерировать это из модели.

Ответ 3

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

То, что вы называете "база данных как крепость", на самом деле является единственным возможным способом реализации единой точки правды.

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

Ответ 4

Структура Model-View-Controller является одним из способов решения этой проблемы. Сообщество rails использует аналогичную концепцию...

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

Ответ 5

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

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

Ответ 6

База данных как крепость - это бред для реляционных баз данных. Для этого вам нужен OODB.