куда поместить Business Logic, AppLayer или DataLayer?

Question

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

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

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

В настоящее время мы планируем перенести все ядро ​​на новую версию (включая дизайн базы данных). И мне нужно несколько примеров из:

• Почему бизнес-логика в базе данных иногда ЗЛО ?
• Сколько и когда рекомендуется использовать бизнес-логику в базе данных ?
• Почему бизнес-логика на уровне приложений лучше для корпоративных приложений. ?

Язык приложения: Java
База данных: Oracle11g
Приложение будет иметь Службы, служащие в качестве страниц HTTP и веб-сервисов.

Answer 1

Дрянной код действительно трудно поддерживать.Такова природа дерьмового кода, а не того, где он находится.Переход к «дрянному коду во внешнем интерфейсе» - это не совсем решение.

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

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

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

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

Но, конечно, нет единого строгого универсального ответа.

Answer 2

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

1. Нельзя выполнить модульный тест чисто:

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

2. Заглушка и насмешка всего слоя :

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

3. Уровни :

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

Answer 3

Читали ли вы эти темы AskTom?

• Разработка приложения - логика в базе данных против логики на сервере веб (приложений)
• бизнес-логика- PL / SQL против Java - Reg
• J2EE и хранимые процедуры Oracle

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

Answer 4

Может быть плохой выбор дизайна (не ЗЛО), если

1. Требуется поддержка нескольких поставщиков баз данных.
2. Вам необходимо поддерживать разные версии базы данных
3. Вам необходимо поддерживать разные редакции базы данных
4. Вы можете ПОКАЗАТЬ, что добавление логики на уровень, не связанный с базой данных, приведет к снижению нагрузки на ЦП на сервере базы данных, и это приведет к экономии затрат на соответствующую лицензию. Если добавление этой логики на уровень, не связанный с базой данных, приводит к увеличению количества запросов к базе данных, увеличению сетевого трафика, увеличению числа используемых сеансов базы данных, дублированию кэширования данных и т. Д., То вы можете обнаружить, что фактически добавляете нагрузку на уровень базы данных и ничего не сохраняете .
5. Злоупотребление существующим набором навыков. Было бы мало смысла в разработке нового приложения на PL / SQL (или Ruby или .Net), если весь ваш персонал владеет Java. Точно так же, если ваши сотрудники обладают навыками PL / SQL, перестроить на Java будет дорого.
6. Отсутствие или затраты на оснастку. Несмотря на то, что существуют тестовые среды для Oracle, коммерческие (например, от Quest) лучше, чем среды с открытым исходным кодом.

Answer 5

- Почему бизнес-логика в базе данных иногда является ЗЛОЙ?

1. Как реализовать ведение журнала, если вы используете БД? Не говорите мне, что вы регистрируете его в БД. :)
2. Трудно увеличить.
3. Обычно скрипт базы данных труднее читать.
4. Сложнее проверять и издеваться.
5. Что делать, если вам нужно изменить базу данных? Например, ваша лицензия Oracle становится недоступной для вашей компании, и вы должны изменить ее на другую базу данных. Миграция будет большой проблемой.

- Сколько и когда Бизнес Логика в База данных является хорошей практикой?

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

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

Ответы такие же, как и у первых ответов.

Answer 6

Почему бизнес-логика в базе данных иногда является ЗЛОЙ? Вам нужно проработать каждое обновление каждого поставщика, возникнут проблемы, если вы хотите перенести поддержку от одного поставщика к другому. Дорого, как упоминалось в одном из постов.

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

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

Answer 7

Проблема с бизнес-логикой в ​​базе данных

• Дорого в масштабе. Вы используете oracle, так что вы знаете, сколько денег стоит добавить еще одну 16-ядерную коробку, которая работает под управлением oracle, вероятно, около $ 750 000.
• Вы заблокированы для поставщика БД (также с точки зрения технологии, вы не сможете перенести свой код).

Преимущество

• Одна остановка: все клиенты БД будут работать по одной логике. Если у вас будет несколько интерфейсов, то все могут использовать одну и ту же логику.

Я работал в страховой компании, у которой была вся логика в БД, и это было более чем хорошо, но ОЧЕНЬ дорого. Я думаю, что любой ответ на ваш вопрос будет очень абстрактным, поскольку нужно принять во внимание много моментов, чтобы принять такое большое архитектурное решение.

Answer 8

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

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

Каноническая книга на эту тему: Домен-управляемый дизайн .

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