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

Question

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

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

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

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

Answer 4

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