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

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

Это действительно зависит от вас, если вы согласны.

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

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

Вы также должны учитывать основные компетенции. Являются ли ваши разработчики главным образом разработчиками прикладного уровня, или они в основном являются DBA-типами?

Ответ 5

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

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

Ответ 6

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

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

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

Ответ 7

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

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

Ответ 8

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

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

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

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

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

Ответ 9

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

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

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

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

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

Ответ 10

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

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

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

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

Ответ 11

Ввод кода на прикладном уровне приведет к созданию независимого от DB приложения.

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

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

Ответ 12

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

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

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

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

Однако код внутри базы данных намного сложнее управлять. Там нет надлежащей среды - нет "PATH", ссылок на каталоги или других переменных среды - для обеспечения любого удобного контроля над используемым программным обеспечением; у вас есть постоянный, глобально связанный набор прикладных программ, застрявших в базе данных, в браке с данными.

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

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

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

Ответ 13

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

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

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

Ответ 14

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

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

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

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

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

Ответ 15

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

Ответ 16

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

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

Ответ 17

Уровни приложения для бизнеса:

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

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

2. Обработка

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

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

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

Что происходит Где

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

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

Ответ 18

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

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

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

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

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

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

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

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

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

Ответ 19

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

И мы знаем, где это, не нужно искать через акров решений и кода!

Ответ 20

Ответ 21

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

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

Ответ 22

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

Ответ 23

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

Ответ 24

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

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

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

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

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