Как Вы сохраняете свои бизнес-правила DRY?
В идеальном приложении каждое бизнес-правило существовало бы только однажды.
Я работаю на магазин, который осуществляет бизнес-правила в как можно больше в базе данных. Во многих случаях для достижения лучшего пользователя испытывают, мы выполняем идентичные проверки на стороне клиента. Не очень DRY. Будучи ТОЧЕЧНЫМ пуристом, я ненавижу это.
На другом конце спектра некоторые магазины создают немые базы данных (наклоны сообщества направляющих в этом направлении) и понижают бизнес-логику к отдельному уровню. Но даже с этим гвоздем, некоторая логика проверки заканчивается повторенная сторона клиента.
Для дальнейшего усложнения ситуации я понимаю, почему базу данных нужно рассматривать как крепость и таким образом, я соглашаюсь, что проверки осуществляются/повторяются в базе данных.
Попытка осуществить проверки в одном месте не легка в свете конфликтующих проблем - остаются DRY, сохраняют базу данных крепостью и обеспечивают хороший пользовательский опыт. У меня есть некоторая идея для преодоления этой проблемы, но я предполагаю, что там лучше.
Мы можем сбалансировать эти конфликтующие проблемы способом DRY?
6 ответов
Любой, кто не обеспечивает соблюдение необходимых бизнес-правил в базе данных, где им и место, будет иметь плохие данные, это просто. Целостность данных - это работа базы данных. На базы данных влияет гораздо больше источников, чем приложение, и устанавливать необходимые правила только в приложении - недальновидно. Если вы сделаете это, вы получите плохие данные от импорта, от других приложений при их подключении, от специальных запросов для исправления больших объемов данных (например, увеличение всех цен на 10%) и т.д. В высшей степени глупо применять правила только через приложение. Но опять же, я тот человек, которому приходится исправлять плохие данные, попадающие в плохо спроектированные базы данных, где разработчики приложений думают, что они должны делать что-то только в приложении.
Во многих случаях данные живут долгое время после приложения. Когда это происходит, вы также теряете правила.
Инфраструктура модель-представление-контроллер - один из способов решения этой проблемы. Сообщество rails использует аналогичную концепцию ...
Основная идея заключается в том, что вся бизнес-логика обрабатывается в контроллере, а там, где правила должны применяться в представлении или модели, они передаются в него контроллером.
В некотором смысле, четкое разделение задач, когда вся бизнес-логика существует в одном ядре, является утопической фантазией, которую трудно поддерживать
Не могу понять, почему.
обрабатывают всю бизнес-логику на отдельном уровне (в Rails модели будут содержать «большую часть» этого)
Верно. Django также делает то же самое.
некоторая бизнес-логика в конечном итоге перетекает в другие места (в Rails она может перетекать на контроллеры
Не совсем. Бизнес-логика может - и должна - находиться на уровне модели. Часть ее будет закодированы как методы классов, библиотек и других наборов логики, которые можно использовать где угодно. Django делает это с объектами формы, которые проверяют ввод. Они исходят из модели, но используются как часть интерфейсного HTML, а также массовые загрузки.
Нет причин для определения бизнес-логики где-либо еще. Ее можно использовать на других уровнях, но она должна быть определена в модели.
Используйте уровень ORM для генерации SQL из модели. Все в одном месте.
[база данных] построена на ограничениях, которые заставляют ее отклонять неверные данные
Я думаю, что это неправильное понимание Сообщение Database As A Fortress . В нем говорится: «Надежная модель данных», «отвергайте данные, которые не принадлежат, и чтобы предотвратить отношения, которые не имеют смысла». декларативная ссылочная целостность.
Слой ORM может генерировать это из модели.
Ну, в общем, бизнес-правила - это гораздо больше, чем наборы ограничений, поэтому очевидно, что не все бизнес-правила можно поместить в базу данных. С другой стороны, HLGEM указал, что наивно ожидать, что приложение будет выполнять всю проверку данных: Я могу подтвердить это на собственном опыте.
Я не думаю, что существует хороший способ поместить все бизнес-правила в одно место, чтобы они применялись на клиенте, на стороне сервера и в базе данных. Я живу с бизнес-правилами на уровне сущностей (поскольку hibernate воссоздает их на уровне базы данных) и остальными правилами на уровне служб.
Проблемы базы данных как крепости и единой точки истины - одно и то же. Они не исключают друг друга. Так что нет необходимости их «уравновешивать».
То, что вы называете «базой данных как крепостью», на самом деле является единственным возможным способом реализации единой точки истины.
«База данных как крепость» - это хорошо. Это означает, что база данных заставляет держаться подальше от всех, кто не хочет подчиняться (правда, база данных должна придерживаться). То, что так много людей считают, что проблема (а не решение , которым оно является на самом деле), все говорит о том, как большинство пользователей баз данных думают о важности «истины» (в отличие от «У меня есть это чертовски много объектов, которые мне нужно сохранить, и я просто хочу, чтобы база данных делала это, несмотря на любые бизнес-правила, какие бы они ни были. ").
Database-as-a-fortress - это чепуха для реляционных баз данных. Для этого вам нужна OODB.