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

Итак, «findOneAndUpdate» требует опции для возврата исходного документа. И, опция:

MongoDB shell

{returnNewDocument: true}

Ссылка: https://docs.mongodb.com/manual/reference /method/db.collection.findOneAndUpdate/

Mongoose

{new: true}

Ссылка: http://mongoosejs.com /docs/api.html#query_Query-findOneAndUpdate

Node.js API-интерфейс драйвера MongoDB:

{returnOriginal: false}

Ссылка: http://mongodb.github.io/node-mongodb-native/3.0/api/Collection.html#findOneAndUpdate

38
задан Matthew Watson 24 September 2008 в 18:24
поделиться

22 ответа

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

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

29
ответ дан Damien_The_Unbeliever 7 July 2019 в 02:54
поделиться

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

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

1
ответ дан Unsliced 7 July 2019 в 02:54
поделиться

Приложение Bussiness 'слои':

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

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

2. При обработке

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

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

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

, Что идет, Где

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

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

2
ответ дан slashmais 7 July 2019 в 02:54
поделиться

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

0
ответ дан core 7 July 2019 в 02:54
поделиться

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

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

1
ответ дан Damien_The_Unbeliever 7 July 2019 в 02:54
поделиться

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

1
ответ дан 7 July 2019 в 02:54
поделиться

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

  • пригодность для обслуживания
  • надежность

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

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

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

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

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

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

<час>

, Конечно, все изменяется, когда Вы ступаете за пределами области RDBMS в системы хранения кортежа как Amazon SimpleDB и BigTable Google. Но это - другая история:)

2
ответ дан Dirk Stoop 7 July 2019 в 02:54
поделиться

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

2
ответ дан RoadWarrior 7 July 2019 в 02:54
поделиться

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

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

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

4
ответ дан Shimi Bandiel 7 July 2019 в 02:54
поделиться

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

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

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

3
ответ дан Alvaro 7 July 2019 в 02:54
поделиться

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

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

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

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

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

3
ответ дан dkretz 7 July 2019 в 02:54
поделиться

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

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

2
ответ дан 7 July 2019 в 02:54
поделиться

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

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

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

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

5
ответ дан tuinstoel 7 July 2019 в 02:54
поделиться

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

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

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

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

Hope, которая помогает.

5
ответ дан Nick Pierpoint 7 July 2019 в 02:54
поделиться

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

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

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

6
ответ дан Foo42 7 July 2019 в 02:54
поделиться

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

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

6
ответ дан James Drinkard 7 July 2019 в 02:54
поделиться

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

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

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

, Если Вы используете Oracle для разработки приложения, тогда МН / SQL, очевидный выбор как язык. Это, очень сильно связано с данными, постоянно улучшаемыми в каждом повторно генерировать, и любое достойное средство разработки идет в integratePL/SQL разработку с CVS или Подрывную деятельность или somesuch.

веб-приложение Oracle среда разработки Экспресса даже создается 100% с МН / SQL.

6
ответ дан David Aldridge 7 July 2019 в 02:54
поделиться

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

Некоторые системы, которые я поддерживаю, прошли следующий UIs за прошлые 10-15 лет: Формы Oracle / Визуальный Основной CGI / CGI Perl / Сервлет ASP/Java. Одна вещь, которая не изменилась - реляционная база данных и хранимые процедуры.

7
ответ дан IK. 7 July 2019 в 02:54
поделиться

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

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

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

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

9
ответ дан Jon Limjap 7 July 2019 в 02:54
поделиться

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

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

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

34
ответ дан Ash 7 July 2019 в 02:54
поделиться

Единственной вещью, которая входит в базу данных, являются данные.

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

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

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

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

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

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

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

4
ответ дан S.Lott 7 July 2019 в 02:54
поделиться

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

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

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

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

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

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

28
ответ дан Mendelt 7 July 2019 в 02:54
поделиться
Другие вопросы по тегам:

Похожие вопросы: