Бизнес-логика: база данных или уровень приложения

Размещение кода на уровне приложения приведет к созданию независимого от БД приложения.

Иногда из соображений производительности лучше использовать хранимые процедуры.

Это (как обычно) зависит от требований приложения.

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

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

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

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

И мы знаем, где он находится, без необходимости перебирать акры решений и кодовую базу!

Поддерживаемость вашего кода всегда является большой проблемой при определении того, куда должна идти бизнес-логика.

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

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

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

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

Единственные веские причины для размещения кода в хранимых процедурах: если это дает существенное и необходимое преимущество в производительности или если один и тот же бизнес-код должен выполняться на нескольких платформах (Java, C#, PHP). Даже при использовании нескольких платформ существуют альтернативы, такие как веб-службы, которые могут лучше подходить для совместного использования.

Масштабируемость также является очень важным фактором для использования бизнес-логики на промежуточном уровне или уровне приложения, а не на уровне базы данных. Следует понимать, что DatabaseLayer предназначен только для взаимодействия с базой данных, а не для управления тем, что возвращается в базу данных или из нее.

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

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

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

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

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

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

Будет сложно заставить несколько приложений работать с одной и той же базой данных. Изменения в одном приложении приведут к поломке других. Это может быстро превратиться в кошмар обслуживания. Так что на самом деле это не масштабируется.

С практической точки зрения, SQL - не лучший язык для понятной реализации бизнес-логики. SQL отлично подходит для операций, основанных на наборах, но в нем отсутствуют конструкции для «программирования в целом», трудно поддерживать большое количество хранимых процедур. Современные объектно-ориентированные языки лучше подходят и более гибкие для этого.

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

Это действительно ваше дело, пока вы последовательны.

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

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

Также следует учитывать профильные компетенции. Ваши разработчики в основном разработчики уровня приложений или они в первую очередь администраторы баз данных?

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

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

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

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

Бизнес-логика обычно воплощается в объектах и ​​различных языковых конструкциях инкапсуляции, наследования и полиморфизма. Например, если банковское приложение передает деньги, может быть тип Money, который определяет бизнес-элементы того, что такое «деньги». Это в отличие от использования примитивной десятичной дроби для представления денег. По этой причине хорошо спроектированное ООП - это то место, где живет «бизнес-логика», а не строго на каком-либо уровне.

Слои бизнес-приложений:

1. Пользовательский интерфейс

Это реализует представление бизнес-пользователя о работе h (is / er). В нем используются термины, которые знакомы пользователю.

2. Обработка

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

3. База данных

Это может быть: нормализованная последовательная база данных (стандартные СУБД на базе SQL); объектно-ориентированная база данных, хранящая объекты, обертывающие бизнес-данные; и Т. Д.

Что идет Куда

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

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

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

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

Конечно, есть большая разница между способностью составить SQL-запрос и «сильными навыками работы с базами данных» - если ваша команда ближе к первому, чем к второму, то поместите логику в приложение, используя одну из гибернаций этого мира. (или смени свою команду!).

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

Надеюсь, это поможет.

Единственное, что хранится в базе данных, - это данные.

Хранимые процедуры - это кошмар обслуживания. Это не данные, и они не принадлежат базе данных. Бесконечная координация между разработчиками и администраторами баз данных - это не более чем организационные трения.

Трудно поддерживать хороший контроль версий хранимых процедур. Код вне базы данных очень легко установить - если вы думаете, что у вас неправильная версия, вы просто выполняете SVN UP (возможно, установку), и ваше приложение возвращается в известное состояние. У вас есть переменные среды, ссылки на каталоги и множество средств управления средой над приложением.

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

Однако с кодом внутри базы данных управлять намного сложнее. Нет надлежащей среды - нет «ПУТИ», ссылок на каталоги или других переменных среды - чтобы обеспечить какой-либо полезный контроль над используемым программным обеспечением; у вас есть постоянный, глобально связанный набор прикладного программного обеспечения, застрявшего в базе данных, связанного с данными.

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

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

[В примерах, которые я видел, старое приложение представляло собой плохо спроектированный беспорядок; когда были написаны хранимые процедуры, была изменена архитектура приложения. Я думаю, что изменение дизайна оказало большее влияние, чем изменение платформы.]

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

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

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

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

Использование SP также сильно зависит от базы данных, которую вы собираетесь использовать. Если вы не рассматриваете независимость базы данных, то у вас будет совсем другой опыт использования T-SQL или PL / SQL.

Если вы используете Oracle для разработки приложения, PL / SQL - очевидный выбор в качестве языка. Он очень тесно связан с данными, постоянно улучшается в каждой версии, и любой достойный инструмент разработки будет интегрировать разработку PL / SQL с CVS, Subversion или чем-то еще.

Веб-среда разработки Oracle Application Express даже на 100% построена на PL / SQL.

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

Некоторые из поддерживаемых мной систем за последние 10-15 лет прошли через следующие UI: Oracle Forms / Visual Basic / Perl CGI / ASP / Java Servlet. Единственное, что не изменилось - реляционная база данных и хранимые процедуры.

ИМХО. Есть два противоречивых вопроса, связанных с определением того, где находится бизнес-логика в приложении, управляемом реляционной базой данных:

• ремонтопригодность
• надежность

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

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

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

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

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

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

Конечно, все меняется, когда вы выходите из области СУБД в системы хранения кортежей, такие как Amazon SimpleDB и Google BigTable. Но это совсем другая история :)

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

СУБД - очень могущественный зверь, а это значит, что правильное или неправильное обращение принесет большую пользу или большую опасность. К сожалению, в слишком многих организациях основное внимание уделяется персоналу, занимающемуся программированием; Навыки dbms, особенно навыки разработки запросов (в отличие от административных), игнорируются. Что усугубляется тем, что способность оценивать навыки dbms также, вероятно, отсутствует.

И есть несколько программистов, которые в достаточной мере понимают то, чего они не понимают в базах данных.

Отсюда популярность субоптимальных концепций, таких как Active Records и LINQ (чтобы внести очевидную предвзятость). Но они, наверное, лучший ответ для таких организаций.

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

В настоящее время возможно отправить на подрыв сохраненный код процедуры и отладить этот код с помощью хорошей инструментальной поддержки.

Если вы используете хранимые процессы, которые объединяют операторы sql, вы можете уменьшить объем трафика данных между приложением и базой данных, уменьшить количество вызовов базы данных и получить большой прирост производительности.

Когда мы начали сборку на C#, мы приняли решение не использовать хранимые процессы, но теперь мы перемещаем все больше и больше кода в хранимые процессы. Особенно пакетная обработка.

Однако не используйте триггеры, используйте сохраненные процедуры или лучшие пакеты. Триггеры снижают ремонтопригодность.

Это континуум. ИМХО самый большой фактор - это скорость. Как вы можете заставить эту присоску работать как можно быстрее, при этом придерживаясь хороших сторон программирования, таких как ремонтопригодность, производительность, масштабируемость, безопасность, надежность и т. д. Часто SQL - это самый краткий способ выразить что-то, а также бывает наиболее производительный во многих случаях, за исключением строковых операций и т. д., но здесь могут помочь ваши процессы CLR. Я считаю, что нужно обильно разбросать бизнес-логику везде, где, по вашему мнению, она лучше всего подходит для данного дела. Если у вас есть группа разработчиков приложений, которые надирают свои штаны, глядя на SQL, позвольте им использовать логику своего приложения. Если вы действительно хотите создать высокопроизводительное приложение с большими наборами данных, поместите в БД как можно больше логики. Увольняйте своих администраторов баз данных и дайте разработчикам полную свободу над своими базами данных Dev. Не существует одного ответа или лучшего инструмента для работы. У вас есть несколько инструментов, так что станьте экспертом на всех уровнях приложения, и вскоре вы обнаружите, что тратите гораздо больше времени на написание красивого и выразительного SQL там, где это оправдано, и на использование уровня приложения в других случаях. Для меня в конечном итоге сокращение количества строк кода - это то, что ведет к простоте. Мы только что преобразовали приложение с расширенными функциями sql с всего лишь 2500 строками кода приложения и 1000 строками SQL в модель предметной области, которая теперь имеет 15500 строк кода приложения и 2500 строк SQL, чтобы достичь того, что делало бывшее приложение с расширенными функциями sql. Если вы можете оправдать 6-кратное увеличение кода как «упрощенное», тогда вперед.

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

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

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

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

И последнее: есть еще одна группа, в которой я работаю в настоящее время, которая выполняет огромную работу с базами данных для исследований, и объем данных, с которыми они имеют дело, огромен. Тем не менее, для них у них нет бизнес-логики в самой базе данных, но они хранят ее на уровне приложения / среднего уровня. Для их дизайна подходящим местом для этого был уровень приложения / среднего уровня, поэтому я бы не стал использовать размер таблиц как единственное соображение при проектировании.