Куда поместить 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. Что делать, если вам нужно изменить базу данных? Например, ваша лицензия Oracle становится недоступной для вашей компании, и вы должны изменить ее на другую базу данных. Миграция будет большой проблемой.

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

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

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

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

Answer 5

Это может быть плохой выбор дизайна (не зло), если

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

Answer 6

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

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

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

Answer 7

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

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

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

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

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

Answer 8

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

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

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

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