29 июля 2009 в 19:17

Где наша бизнес-логика, сынок? перевод

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

Отдельное спасибо автору, за разрешение отдельной публикации.

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


Где наша бизнес логика, сынок?


Введение


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

О статье


То, что я здесь опишу, один из методов построения n-звенных систем с точки зрения проектирования и архитектуры. Эта статья не фокусируется на коде. Есть много методов построения n-звенных систем, это только один из них. Если вы строите систему, я надеюсь, вы найдете хороший совет, методику или шаблон использования этого подхода.
Хотя данная статья может предлагать несколько отправных точек из «стандартных методов», все в этой статье базируется на Шаблонах и Методах Microsoft и описывается в Designing Data Tier Components and Passing Data through Tiers и других документах.

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

Цель


Спросите любого разработчика, где должна быть бизнес логика, и получите ответ: «Конечно же в бизнес слое».
Спросите того же разработчика, где находится бизнес логика в их организации, и снова услышите: «Конечно же в бизнес слое».

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

Термины


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

Звено (tier)

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

Слой (layer)

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

Развитие проблемы


Десктоп

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

image

Клиент-сервер

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

image

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

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

image

3-звенка

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

Стало популярным объединение подключений в пул, однако для реализации пула подключений в системе с множеством отдельных клиентов, необходимо внедрить третье звено между клиентом и сервером. Среднее звено так и стало называться «среднее звено». В большинстве случаев среднее звено существовало только для управления пулом соединений, но в некоторых случаях бизнес логика начала перемещаться в среднее звено потому, что языки разработки (C++, VB, Delphi, Java) гораздо лучше подходили для реализации бизнес логики, чем языки хранимых процедур. Вскоре стало очевидно, что среднее звено –это наилучшее место для бизнес логики.

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

Что такое бизнес логика?


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

Сервер базы данных – это уровень хранения. Базы данных разработаны для хранения, получения и обновления данных с максимально высокой эффективностью. Функционал зачастую является СУПОм (Создать, Удалить, Получить, Обновить). Некоторые базы данных СУПОм и являются, но разговор не об этом.

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

Удалить Покупателя


И все это относится не только к сложным вещам. Давайте представим себе простую задачу и такую, которую зачастую даже не относят к бизнес логике. Задача – Удалить Покупателя. Практически во всех системах, что я видел, удаление покупателя обрабатывается исключительно хранимой процедурой. Однако в удаление покупателя довольно многие решения должны быть приняты на уровне бизнес логики. Можно ли удалить покупателя? Какие процессы должны быть запущены до и после? Какие предосторожности должны быть соблюдены? Из каких таблиц записи должны быть удалены или обновлены в последствие?

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

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

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

Я часто встречал хранимые процедуры вроде этой:
sp_DeleteCustomer(x)
Select row in customer table, is Locked field
If true then throw error
Sum total of customer billing table
If balance > 0 then throw error
Delete rows in customer billing table (A detail table)
if Customer table Created field older than one year then
Insert row in survey table
Delete row in customer table


Регулярно часть бизнес логики отъезжает в бизнес слой.
Business Layer (C#, etc)
Select row in customer table, is Locked field
If true then throw error.
Sum total of customer billing table
If balance > 0 then throw error.
if Customer table Created field older than one year then
Insert row in survey table
Call sp_DeleteCustomer
sp_DeleteCustomer(x)
Delete rows in customer billing table (A detail table)
Delete row in customer table


В этом случае, часть бизнес логики была перемещена, но не вся. Некоторые таблицы обрабатываются и в слое бизнес логики. База данных не должна иметь ни малейшего представления о том, какие таблицы формируют покупателя в бизнес слое. Для всех трех операций, бизнес слой должен выдать SQL команду или вызвать три отдельные хранимые процедуры для реализации функционала в приведенной sp_DeleteCustomer.
Передав всю бизнес логику в бизнес слой, мы получим:
Business Layer (C#, etc)
Select row in customer table, is Locked field
If true then throw error.
Sum total of customer billing table
If balance > 0 then throw error.
if Customer table Created field older than one year then
Insert row in survey table
Call sp_DeleteCustomer
Delete rows in customer billing table (A detail table)
Delete row in customer table


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

Переведя даже модификацию таблиц в бизнес слой, мы получим следующие преимущества:
  • Перенос базы данных может быть осуществлен с меньшими усилиями, т.к. все эти хранимые процедуры не нужно отлаживать для каждой СУБД.
  • Модификация проще, т.к. вся логика содержится в одном слое, а не в двух.
  • Отладка проще – логика не размазана по двум слоям.
  • Другая логика не сможет проскользнуть в хранимую процедуру только потому, что «так проще».

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

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

Форматирование


Давайте разберем еще один пример, обнаруженный мной и сеющий зерна войны среди разработчиков – является это бизнес логикой или нет. Я расскажу, почему я считаю это бизнес логикой, а не пользовательским интерфейсом или хранением. Этот пример не относится к легко реализуемому форматированию. Пример, который я буду использовать, — телефонные номера.
Каждая страна имеет свой собственный формат отображения телефонных номеров в приятной глазу манере. В некоторых странах их даже больше одной. Ниже несколько примеров:

Кипр:
+357 (25) 66 00 34
+357 (25) 660 034
+357 25 660 034
+357 2566 0034
Германия:
+49 211 123456
+49 211 1234-0
Северная Америка (США, Канада)
+1 (423) 235-2423
+1-423-235-2423
Россия:
+7 (812) 438-46-02
+7 (812) 438-4602

В Германии есть даже специальный официальный стандарт для форматирования – DIN 5008.

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

Договоримся форматировать телефоны следующим образом:
  • Данные поступают в различных форматах.
  • У каждой страны есть свой уникальный способ отображать телефоны.
  • Форматы некоторых стран не просты и меняются в зависимости от первых цифр.
  • Первые несколько цифр (обычно код страны и региона) не всегда имеют фиксированную длину. Например, в России, 812 – код города Санкт-Петербург, 495 – Москва, но некоторые регионы имеют 4 знака (3952). Это приводит и к изменению и общей длины, и формата, в зависимости от регионального кода.
  • При выходе новых законов, появлении новых операторов, интеграции Евросоюза, обновления телефонных систем и еще множестве всего, форматы и длины телефонов меняются довольно часто в глобальном масштабе. За недавнее время Кипр сменил свой код страны дважды: один раз при обновление системы, второй раз из-за возросшего числа сотовых операторов. Имея сотни стран во всем мире, следует ожидать изменений на регулярной основе.

Обычно делается следующее, все не цифровые символы убираются и номер становится похожим на:
Phone: 35725660034

Иногда отделяется код страны и номер становится таким:
PhoneCountry: 357
PhoneLocal: 25660034

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

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

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

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

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

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

Исключения


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

Я еще вернусь в статье к этой проблеме.

Сегодняшние системы


Клиент-сервер

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

image

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

N-звенка

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

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

Сценарий 1

Типичное распределение бизнес логики по n-звенной системе:

image

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

Сценарий 2

Другой типичный сценарий:

image

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

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

image

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

Консолидация

Вместо всего вышеперечисленного, бизнес слой должен содержать все бизнес правила.

image7

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

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

image

Переезд на центральный узел


Скользкий путь

При переходе на центральный узел всегда есть искус «реализовать эту часть в хранимой процедуре». Потом «ту» и «вот эту». И скоро вы окажетесь в той же ситуации, что и были, без существенных изменений.

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

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

Дешевле


Звучит несколько странно, что покупка железа может сделать дешевле. Но при внедрении серверов среднего звена, практически никакого дополнительного ПО, кроме ОС, не требуется. А стоимость наращивания мощности сервера базы данных существенна по следующим причинам:
  • Сервера баз данных, как правило, более высокого класса, чем сервера среднего звена, и стоят дороже.
  • Базы данных зачастую лицензируются на процессор и добавление процессора – дорогостоящая процедура в терминах лицензий. Лицензионные сборы могут составлять от 5000 до 40000 долларов на процессор.

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

Проще

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

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

Топология


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

image

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

image

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

Вырасти середину


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

image

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

image

Бутылочное горлышко


Давайте посмотрим еще раз на один из предыдущих графиков:

image

Какое единственное узкое место в системе? Какое из звеньев имеет выраженный предел наращивания? Это однозначно база данных. Все упирается в базу данных.

image

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

Сложности


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

Привычки

Есть поговорка: «сложно избавиться от старых привычек». Это применимо и к команде. В команде вам нужно убедить не только себя, но и большинство команды.

Процедуры

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

Администраторы баз данных

Это рискованное утверждение. Настолько рискованная, что есть еще кое-что, что нужно сказать. Если вы администратор БД или разработчик, пожалуйста, не воспринимайте то, что я хочу сказать как стереотип или правду о всех администраторах баз данных. Однако, это превалирует и часто встречается. Если вы администратор БД, который не попадает под это описание – браво! Вы Президент баз данных, а не лорд баз данных.

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

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

Администраторы баз данных не мигрируют по компаниям с такой частотой как разработчики, и многие из них руководят корпоративной базой данных на протяжении последних 10 и даже 20 лет. База данных очень важная для них вещь, и они не хотят идти ни на какие сделки. Они построили свое королевство и не хотят потерять контроль. Заставить такого администратора отдать часть безопасности и реализации можно только в серьезной битве и при поддержке менеджмента.

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

Инструментарий

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

Решения


Архитектура

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

Обучение ассистентов

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

Все равно процесс затронет ассистентов. Они пишут запросы, оптимизируют их и обслуживают базу данных. Также они должны отслеживать SQL, приходящий из среднего звена, и производительность БД. Ассистенты также продолжат проектировать архитектуру БД.

Обучение менеджеров

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

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

Что еще почитать


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

Во время своей работы, я прочитал много материала, написанного «экспертами». Большая часть их была написана разработчиками, хорошими в создании теорий и обучении других в том как надо делать, но никогда не применявшими свои собственные методы на практике. Другие были написаны опытными разработчиками с узким кругозором, а эти знания очень зависят от конкретного приложения. Когда разработчики читают такие материалы, они становятся уверенны в том, что есть только один путь решения проблемы. Разработчикам нужно мыслить шире и понимать, что описанное решение проблемы является только направлением, а не доктриной.

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

Пожалуйста, обратите внимание на Designing data tier components and passing data through tiers.

Заключение


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

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

UPD: по подсказке maovrn перенесено в «Проектирование и рефакторинг».
UPD1:
Для тех кто в танке:
1. На Хабре есть правила оформления переводов см. помощь
2. Для тех, кто не может осилить п.1. автор статьи Chad Z. Hower aka Kudzu
3. Для тех, кто читает только середину без начала и конца — статье три года. Потому, как минимум некорректно объявлять автора статьи безграмотным на основание того, что он не читал на момент публикации материалов, выпущенных после публикации.
4. Если данный апдейт вас задел — это ваши проблемы.
Автор оригинала: Chad Z. Hower aka Kudzu
Alexander Kouznetsov @unconnected
карма
172,7
рейтинг 0,0
Самое читаемое Разработка

Комментарии (121)

  • 0
    Отличная статья! Все проблемы как с нас списаны. Дам прочитать нашему архитектору, будем задумываться о переносе большей части логики с сервера БД на сервер приложений.
  • +7
    Недавно общался с человеком на похожую тему. Распинался о правильном проектировании систем, культуре программирования и т.п. В ответ услышал циничное: «Зачем все это? Как-нибудь слепим, поставим еще 50 серверов и уже начнем зарабатывать деньги, когда ты не выполнишь и половину работы». Так и не нашелся, что сказать в ответ.
    • +2
      любые практики и методики — это всегда сделка, между тем что правильно и тем, что нужно :)
      идеальный продукт никому не нужен, и лучший не нужен.
      нужен просто хороший
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Да это сплошь и рядом!
          Руководство интересует только чтобы
          а) было сделано быстро
          б) работало

          Все!
          И никого не корябает «правильность» и «красота» реализации.
          И их тоже можно понять. Им денег надо заработать а не осчастливить всех вокруг…
          • +2
            Обычно руководство и не должна интересовать «правильность» хотя бы потому что они компетентны в ток как продать, а как реализировать это не их проблема.
            А реализировать «правильно» с твоей точки зрения это твой интерес, чтобы потом 70% времени который отойдёт на сопровождение продукта ты и твои колеги не вспоминали с матами свою расхлябаность.
            Привычка писать чисто и не срезать углы это как привычка не мусорить около себя и чистить зубы, обычно это прививается старшими и или более авторитетными разработчиками, а также зависит от принятой культуры разработки, если её не привить вовремя то приходится ходить з делезной линейкой и жестоко отчитывать при каждом код ревью. Ах да, забыл упомянуть у «И никого не корябает «правильность» и «красота» реализации.» обычно нет код ревью даже постфактум.
            • 0
              Абсолютно точно. Там где на решение «как делать» хоть как-то влияет высокое руководство — там получается то самое «И никого не корябает «правильность» и «красота» реализации».

              «код ревью» — таких слов высокое руководство даже не знает. :) Системы самонаводящиеся… «Выстрелил и забыл». То есть «продал и забыл». :)
              • 0
                Не знаю что у вас за руководство. Но система контроля версий, код ревью, обязательный анализ архитектуры кем-то из другого отдела это то что моё руководство делает. Оно может и не обязано понимать технических деталей, но понимает что отдать всё на самотёк это большой риск для проэктов и для компании в целом и в его интересах поставить процес чтобы он был самоисполняющимся и с большой долей вероятности исполнялся в срок и с заданным бюджетом и чтобы инвестиции в системы были не одноразовыми. Если руководство этого не понимает то это бомба с тикающим механизмом. Кстати сейчас в том же офсорсинге каждый заказ я так понимаю на вес золота, потому люди с раздолбайским подходом имеют все шансы занятся другими видами деятельности.

                К слову у нас разрабатывается один проэкт с 2001-го года. С C++/MFC/ActiveX/XML последовательно переползли на C#/ActiveX(почти вычистили)/XML и сейчас проэкты созданые для первых версий можно конвертировать. И движок функционирует по той же самой логике которая была создана изначально. В продукт инвестировано несколько десятков милионов долларов и если бы следовали подходу сделать побыстрее и абы как, то деньги давно пришлось бы списать, а ряду руководителей проэкта поискать работу в другой сфере.
                • 0
                  Круто. А бизнес-логика куда попала? Как в данной статье предлагается? Или как?

                  Что за руководство? Думаю это специфика мелкой конторы пищущий софт по одноразовым заказам.
                  Я знаю что может быть (и должно быть) иначе. Но этот мир несовершенен. :)
          • +1
            Правильная организация модели позволяет избежать дублирования. Одно из следствий отсутствия дублирования — более дешевые изменения, что важно для бизнеса. «Правильная» и «красивая» реализация подразумевает то, что проект будет собран весьма быстро и будет подготовлен к неизбежным изменениям. Если объяснять придерживаясь такой позиции, бизнес все прекрасно понимает.
            • 0
              Полностью согласен.
            • 0
              Дополню. Разработка это инвестиция. Некачественный софт это разовая инвестиция которую обычно приходится списать и начать всё заново. Вменяемое руководство и бизнес это понимают.
    • +4
      > поставить еще 50 серверов

      Да уж, или он ни разу ничего не масштабировал, или это гуру, для которого создавать масштабируемые системы уже давно стало обыденностью.
      • 0
        Все зависит от проекта. Где-то легко поставить 50 серверов, а где-то тяжело.
    • +5
      Если вам сказали все честно, не кривя душой, то вы общались с профессионалом самого высокого уровня. Я серьезно. Интерпрайз это интерпрайз, эти приложения не спасут мир, они просто сделают n рабочих мест для клерков.
      • 0
        Да, а потом самое маленькое изменение в этом 'высоко-профессиональном' приложении будет занимать больше, чем переписка всего заново.
        • 0
          Нет никакой гарантии что в приложении с «навороченной» архитектурой изменения обойдутся дешевле. Даже напротив. И это не мои фантазии — это реальный опыт участия в разработке приложений для очень больших компаний (каких говорить не буду, но поверьте что для очень больших).
          • +1
            С «навороченной» архитектурой — нет, с хорошей архитектурой — да.
            Дело не в том чтобы сделать «архитектуру», дело в том чтобы дополнения более-менее придерживались принципа open-closed — то есть можно было бы добавлять новые штуки, почти не меняя старые.

            У меня тоже есть опыт работы в проектах для больших компаний. Я видел средние проекты, плохие проекты, и хорошие проекты.
            Так вот плохие проекты могут застрять ни на чём на долгое время, а хорошие проекты двигаются вперёд равномерно и довольно неплохо.
            • +1
              Я в целом согласен, но приложение с предельно простой архитектурой («как-нибудь слепим») это вполне себе разновидность хорошей архитектуры.

              • 0
                KISS и YAGNI — обычно и есть хорошая архитектура. Т.е. предельно простая — это, действительно, хорошая архитектура. А вот «как-нибудь» слепим обычно заканчивается хрупким спагетти-кодом.
          • 0
            Есть гарантии, что в приложении с «правильной» архитектурой изменения обойдутся дешевле. «Правильная» — эта та, которая готова к изменениям и постоянном рефакторингу, тому, что обязательно присутствует в любом живом проекте.
        • 0
          И это — чудесно. Потому что масса народа получит на долгое время высокооплачиваемые рабочие места. Начиная от топовых менеджеров, отвечающих за улучшение и повышение эффективности, заканчивая уборщицами на новый этаж офиса.
          Увы, таковы реалии общества потребления. Делать, чтобы было себе, а не миру.
          • 0
            Я (да в общем и компания где я работаю) никогда не работал с целью создать рабочие места таким образом, и сама идея мне неприятна.

            С другой стороны, кто сказал что клиент с таким приложением пойдёт к той же компании, которая его исходно написала? Чаще будет так, что он выслушает estimate и отправится к другим, раз уж всё равно надо переписывать. К индусам или китайцам, например, раз качество всё равно не отличается.
            • 0
              Пропиарились. Почти грамотно (ибо «идея мне неприятна» — несколько эгоцентрично). Здравомыслящий клиент не станет обращаться к тем, кто вместо реализации его идеи — начинает складывать о ней свое мнение. Как правило такие исполнители, если им вдруг что-то «неприятно», начинают делать так, что перестает быть «приятно» клиенту.

              «Чаще будет так… » Выши бы слова да топам в уши. Но увы, увы. Топы слушают не естимат, а про откат, либо смотрят красочность презенташек, али еще на некоторые вещи. А нужный естимат легко получается за счет стандартной операции «следущая итерация». Кроме того, в резюме гораздо солиднее смотрится управление сотней человек, чем десятком. Вот и причина, почему раздувают проекты-штаты.

              Возвращаясь к статье: я счас заканчиваю работать в проекте, который изначально имеет БЛ в ДБ (Oracle). Руководитель этого проекта поднялся на нем за тройку лет с никого до заместителя вице-президента (надеюсь, вы в курсе, кто такие ВП в крупных международных конторах) со штатом в десяток человек.
              • 0
                Здравомыслящий клиент не станет обращаться к тем, кто вместо реализации его идеи — начинает складывать о ней свое мнение


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

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

                Топы в разных компаниях разные, но вообще-то все компании-заказчики, которые я до сих пор видел, были довольно экономны (и чем больше компания, тем более мелочной она часто оказывается).
                • 0
                  Благодарю за развернутый ответ. Я понял Ваше точку зрения.
              • 0
                Возвращаясь к статье: я счас заканчиваю работать в проекте, который изначально имеет БЛ в ДБ (Oracle). Руководитель этого проекта поднялся на нем за тройку лет с никого до заместителя вице-президента


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

                С другой стороны, например, строители у нас строят плохо, а получают сверхприбыли — это тоже пример для подражания?
          • –1
            Перестаньте троллить :)
    • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Конечно исходное приложение быстрее слепить как попало, если оно не сложное.
      А вот добавлять новые возможности вы будете быстрее и без того, чтобы всё сломалось.
      • 0
        Если оно не сложное, то сделать по-нормальному также несложно.
        Так что и здесь «слепить как попало» — не лучший вариант.
    • +1
      Это нормально для небольших проектов. Проект который развивается в течении нескольких лет с таким подходом либо скоро загнётся, либо станет нерентабельным, либо вынужденно будет перепроектирован. Совершенно согласен с автором статьи: база данных должна заниматься только СУПОм и бизнес логику дешевле держать на сервере. А ещё моё личное мнение, что работать со списками гораздо удобней из какого-нибудь языка C#, C++, python, etc., чем из хранимых процедур. И вообще SQL как язык удобен только для консоли, в программировании он не нужен.

      P.S. На холиварные комментарии отвечать не собираюсь. Этот комментарий моё личное мнение.
      • 0
        А ещё моё личное мнение, что работать со списками гораздо удобней из какого-нибудь языка C#, C++, python, etc., чем из хранимых процедур.

        Ну так для этого и были добавлены Java в Oracle, Tcl, Python, Perl в PostgreSQL и т.д.
      • +1
        Я вот тоже слегка удивился тому, что автор с уверенностью(и знанием дела, наверное) говорит о том, что у очень многих даже сейчас бизнес-логика в хранимых процедурах. Может это, конечно, где-то там… в «энтерпрайзе».
        Для меня БД это просто хранилище для объёктов, которое умеет считать минимальные какие-то вещи вроде кол-ва, максимума\минимума и т.п.
    • 0
      Затем, что далеко не всегда всё решается увеличением числа серверов и их мощностей.
      И рано или поздно, как правило, наступает момент, когда новые сервера не помогают, потому что архитектура-то кривая. И иногда, если сразу не подумать, то рефакторинг может очень дорого обойтись…
      Ну и зачем нагружать 50 серверов, если с этим легко могут справиться, скажем 10?
      Но сталкиваться с таким приходится…
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      мы часто решали такие задачи терминальным сервером, не лучшее решение, зато простое как АК и относительно дешевое
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Может быть это дешевле, чем программу переписывать?
          • НЛО прилетело и опубликовало эту надпись здесь
  • +4
    Все правильно написано. Один момент — это применимо только к domain-centric модели в n-tier. В случае, если используется REST-like модель, зачастую желательно business-layer поджимать или к одной, или к другой стороне, убирая ее с шлюза данных.

    Еще один момент (распространненная ошибка) — разрывать business logic layer и data access layer, зачастую на разные машины, чтобы потом героическими темпами по выстругиванию костылей решать эти трудности типа «отсутствующие данные» или «полбазы вынули на запрос» с БД на business layer.
  • +3
    Чувак, я мало что понял, но ты достучался до моего сердца.
    действительно интересная статья, +
  • –11
    Статья устарела
    Сейчас перспектива — облако
    • +8
      В любом облаке слой бизнес-логики отделен от слоя данных.
      Перечитайте статью, а потом почитайте про облака.

      Статья правильная и нужная ;)
      • –1
        Статья очевидная
    • +3
      слышал звон, да не знаешь откуда он.
    • 0
      А мне кажется что в данный момент всё движется к связке ESB+SOA
  • +3
    > В какой блог поместить?
    Предлагаю Проектирование и рефакторинг, т.к. большая часть статьи описывает один из шаблонов проектирования. Плюс небольшие забавные отступления про переубеждение строгих администраторов баз данных можно с натяжкой отнести к рефакторингу.

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

    Про стоимость железа интересно, в этом плане даже не задумывался.
  • +1
    Первая вразумительная статья по противостоянии двухзвенки и трехзвенки. Спасибо, очень интересно.
  • +2
    Обертка, обертка, ...., обертка…

    Парень люди хотят конфету. Берут они конфету, а обертку выбрасывают. И только у вкусных конфет, они разглядывают фантик.
    • –1
      *Не туда вписал.

      А кто автор?
      • 0
        там как бы написано
        Chad Z. Hower aka Kudzu
        • –1
          В теле статьи не было!? Создает проблемы в восприятии. Может следовало бы в начальном абзаце отдельно представить, если дается перевод.
          • 0
            habrahabr.ru/info/help/ — всем новичкам рекомендуется к прочтению
            это утверждение верно для большей части ресурсов
  • –11
    дефис, блять, дефис надо ставить в составных словах, где «бизнес» является первой его частью!
    • –1
      что, стыдно?
      • +1
        А за что стыдится. Это вам с вашим лексикой место на других сайтах. Если есть ошибка можете послать личное сообщение автору и я уверен он вас поблагодарит и исправит. Также вы могли написать коментарий но без б… который тоже бы учли.
        Здесь комюнити технарей, а не грамотеев. Лично для меня русский неродной и я на нём почти не говорю и считаю нормальным ошибатся и исправлять потом свои ошибки. А грубиянов не люблю, судя по минусам не один я такой.
        • –1
          морализаторствуйте тоже, пожалуйста, где-нибудь не здесь
  • 0
    Автор не слышал о бесплатных базах данных?

    Видел несколько проектов, в который декларировался принцип — «Вся логика в базу».
    Вне базы были собственно только шаблоны для генерации html и контроллеры на 3-5 строк.
    Сам успешно их критиковал поначалу. А потом подумал — а ведь они же работают. И это самое главное.

    А бывает еще, когда в принципы разработки приложения включается «Do it as fast as possible». В этом случае database views очень хорошо экономят время.

    • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      То есть быстрее написать логику на SP в MySQL, чем на нормальном языке?
      А если нужна одна и та же логика для многих сущностей?

      Вообще процедурное программирование живёт до какого-то уровня сложности, но я бы не сказал что оно проще, особенно на ограниченном языке типа SQL.
  • +2
    Спасибо автору. Очень качественный материал.
    Грамотно расставлены акценты на системы и на людей.

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

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

    А на счёт того, что безопопасней — регулировать права доступа на много модульных систем бизнес-логики промежуточного слоя или правами к одной большой СУБД, пусть даже по отдельным базам и таблицам, нужно всегда смотреть в каждом конкретном случае.
  • 0
    Черт побери, какая огромная статья!)
    Спасибо автору, материал переведен грамотно.
  • 0
    Отличная статья! Есть кое-какие огрехи перевода, но все равно ставлю плюсы везде, где могу :)
  • 0
    Читал статью и был немного не согласен, но слова про «дублирование немножко бизнес-логики на клиенте и в БД», меня добили и обратили в Вашу веру. Впереди есть очень забавный проект, будем сопротивляться дивному желанию засунуть всего и побольше в хранимки. Хотя, пожалуй, тут тоже надо посидеть, пока есть время и «поиграться».
  • 0
    По-моему, суть статьи можно выразить шестью словами: «Не используй хранимые процедуры, кроме вьюшек!»

    В такой форме можно добавлять эту статью к разным там «10 заповедей программиста» ;)

  • 0
    Допустим необходимо разработать отчет, где реализовывать код на стороне клиента или на стороне сервера приложений?
    • 0
      Вы слышали про OLAP?
      • 0
        У нас развернут OLAP, но его не бывает достаточно. Дело не приципиально в отчете, а в том как бы автор разнес по слоям задачу. Для меня не очевидно.
  • 0
    умоляю, поставьте дефис в заголовке.
  • +2
    На самом деле, базе данных становится не очень хорошо от слишком большого количества загруженных хранимых процедур

    Интересно, на чем основано данное утверждение?

    Вообще почти все доводы автора по поводу снижения производительности системы при использовании ХП для меня звучат не очень убедительно. ИМХО перенос бизнес-логики ближе к данным как раз увеличивает производительность системы снижая расходы на передачу промежуточных данных и их преобразования из объектной модели в реляционную и обратно.
    • +1
      Вы все правильно говорите — необходимо стремиться к наибольшей локальности данных и кода, работающего с ними — это тоже можно считать одной из «заповедей» :)

      Проблема в том, что а) это стремление — не единственный критерий, который нужно учитывать б) попытка соблюдать данную «заповедь» во что бы то ни стало похерила не один проект; по правде говоря, это стремление херит проекты гораздо чаще, чем излишнее распределение — я думаю, любой читающий и пишуший здесь в своей жизни видел тонны write-only бизнес-логики, накрученной в SQL.

      Автор просит руководствоваться здравым смыслом в первую очередь, и не доводить до фанатизма с одной стороны и «я все знаю и так» — с другой, а решать объективно.
      • 0
        Согласен с каждым вашим словом. Но, в отличии от Вас, у автора как-то уж сильно однобоко получилось в сторону того, что хранимые процедуры — зло.
        • –3
          имхо смысл статьи вовсе не в «бизнес-логике», а в том, что:
          среднее звено имеет емкость для роста и гораздо дешевле базы данных

          что вполне логично, для Micro$oft. :)
          • +1
            А можете пояснить, при чем здесь MS? Дело в том, что объективен тот факт, что кластеризовать сервер приложений куда проще, чем БД; и у всех производителей решение виртуализации БД стоит куда дороже, чем средство балансирования нагрузки между узлами с серверами приложений.
            • 0
              какую БД?
              • 0
                Реляционную, естественно. Или вы в Ынтерпрайзе видели на каждом углу schemaless?
                • –1
                  ну вот, а еще спрашиваете «при чем здесь MS?» :)
                  • 0
                    DB2, Sybase, Oracle, PostgreSQL, MySQL, Firebird, Interbase, ЛИНТЕР.

                    Все еще настаиваете, что RDBMS == M$?

                    • 0
                      это вы уже сами додумали. :) речь о том, что сейчас m$ активно продвигается на рынке технологий для создания именно «среднего звена». про то и статья.
          • 0
            для Оракл и Сана тоже ;)
  • +2
    Замечательная статья, разослал ссылки коллегам разработчикам.
  • 0
    Кстати, по поводу хранимок — это отдельная песня; в настоящее время большинство разработчиков склоняются к мысли, что они приемлемы в 2х случаях:
    а) легаси система, когда все работает и нет смысла переделывать
    б) когда БД в проекте занимается специальный выделенный отдел DBA — в таком случае со стороны БД необходимо выставить некоторую поверхность Business API, ее роль как раз и играет набор stor-proces и view.

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

    Еще один тип проблем — SQL своей ограниченностью подталкивает на реализацию в хранимках «финтов ушами» типа динамического SQL, своих xml-парсеров, хранение текстовых констант и шаблонов для UI прямо там и т.п.
  • +2
    Большое спасибо за статью.
    Можно небольшое замечание по переводу? Lord (именно с большой буквы) — это Бог, а не лорд.
    dictionary.reference.com/browse/Lord?r=75&src=ref&ch=dic
    • 0
      да, верно,
    • 0
      спасибо, сразу как-то не уловил, видимо уже под конец не совсем в адеквате был :)
    • 0
      только теперь не знаю как фразу целиком перевести :)
      так что оставлю как есть
  • НЛО прилетело и опубликовало эту надпись здесь
    • –1
      похоже на правду. автор местами путается при использовании терминов layer и tier.
    • +2
      статья как раз о том, что сервер БД пора перестать рассматривать как многоцелевой компонент. сервер БД — это просто шустрое хранилище.
      • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Люди которые мыслят чёрнобелымы категориями обычно ничего хорошего написать не могут. Никому не нужна идеальная система которая никогда не будет написана. Окружающий мир значительно сложнее. И если SQL Server оброс функциями app server это не потому что так маркетологу захотелось, а потому что многим заказчикам это действительно нужно и этим пользуются.
        • 0
          И вдогонку. Я категорически неприемлю подход в котором бизнес слой должен знать больше чем должен о слое БД. Это противоричит идее инкапсуляции. Как раз хорошо когда БД самостоятельно на основе своей структуры произведёт изменение учитывая ограничения, а код бизнеслоя должен думать как исполнить свой контракт и при выполнении транзакции сохранить соглазованость и непротиворечивость даных именно своего слоя.
          Да размазано частично получается но с другой стороны, с какого такого Бизнес слой должен знать как хранятся данные.
          • 0
            >> размазано частично

            Это про ваш комментарий, вестимо, уж извините. Если не сложно, поясните, пожалуйста, следующее:

            >>знать больше чем должен о слое БД
            А что он должен знать?

            >>Это противоричит идее инкапсуляции
            Сам подход Фон-Неймана хранить данные и программу в одной памяти противоречит «абстрактным» принципам инкапсуляции, на которые вы ссылаетесь. Что понимается под инкапсуляцией в вашем примере? Что от чего вы собираетесь изолировать?

            >>с какого такого Бизнес слой должен знать как хранятся данные.
            Весь бизнес-слой — не должен. Должна знать его часть, называемая Repository или Data Access. На этом построена целая технология ORM.
            Иначе, если следовать вашему пониманию, и sql в бизнес-логике недопустим.

            Имхо, вы не понимаете, что вы пишете.
            • 0
              > Имхо, вы не понимаете, что вы пишете.

              Боюсь это не я не понимаю, а автор статьи со своим примером «Удалить покупателя». Идиоту ясно что в приедённом примере нужен DAL слой, да и в книге на которую он ссылается это есть. А как DAL реализируют, какой ORM будет использован это его проблемы и какой там шаблон буде использован AR, Repository или что-то ещё для BL важно только с точки зрения интерфейса взаимодействия явного и неявного контракта.
              В этой статье с претензией на монументальность смешались в кучу люди, кони. Вот новичёк прочитает и начнёт лепить положившись на авторитет Хабрахабра.
              Вот за это люблю rsdn. Там такое не пропустят редакторы.
              • 0
                Ага, вот теперь понял :)
                Не принимайте примеры близко к сердцу. Несомненно, в этой статье, как и в других, есть косяки в деталях. Но она преследует благородную цель — заставить людей думать, что они делают, и ценна хотя бы этим :)
                • +1
                  Кстати у МС-а давно есть более монументальный и новый труд «Microsoft Application Architecture Guide, 2nd Edition» msdn.microsoft.com/en-us/library/dd673617.aspx где я считаю лучше расписано с примерами для типовых приложений.
                  А ещё есть набор хорошых видео и объяснений на кодеплексе:
                  «How To: Design Business Components» apparch.codeplex.com/Wiki/View.aspx?title=How%20To%20-%20Design%20Business%20Components

                  И всё воспринимать с извесной делей скепсиса :)

                  • 0
                    Ага, читал. Труды, конечно, фундаментальные, почти в стиле ALT.NET, особенно первый, но не понравилось ни то ни другое — индусы не могут нормально делать :) Видимо, слишком много скепсиса приложил ))
                    • +1
                      Ну мне помогало по крайней мере чтобы понять почему и как слои должны взаимодействовать с собой. Там всё очень укрупнено.
                      Нужно учитывать что на архитектуру очень часто накладывает отпечаток технологии какие вы используете, часто они принуждают писать в определённом стиле, например блоки из Enterprise Library или Prism.
          • 0
            бизнес слой и не должен знать о структуре данных — об этом должен знать data access layer
            а в целом надо плясать от задачи, потребностей и возможностей
            здравый смысл рулит всегда
        • 0
          Комментарий ни о чем. Куча общих слов. Замените «написана» и «SQL Server» на что угодно, и получится годный наброс :)
          • +1
            Я объяснил свои коментарии ниже. А человек который лезет в БД с DELETE без крайней нужды или не очень компетентен или БД ограничена (я например сейчас работаю с MS SQL CE где нет Stored Procedures).
            Найти несуществующую проблему и потом её решить это верх мастерства.
            Приведённый пример «Удалить покупателя» некоректен потому что там SP должна вызыватся из DAL слоя.
            А из наличных у меня математиков они где-то з 20-й итерации приблизятся к эфективности реализации операций базовой обработки данных к БД что говорить о обычных програмистах которые quicksort не всегда могут правильно реализировать(а если ечесть сколько есть её модификаций). То что лучше всего делается в БД часто стоит делать именно в БД. Разница в производительности твоего кода и обработки в БД может достигать двох-трёх порядков, только за счёт ненужности прогонки данных меж приложением и БД. И приведённые цыфры добавленых лицензий на SQL могут окупиться, потому что если учесть накладные затраты на извлечение и обработку данных, несовершенство и неоптимизированость вашего кода, то стоимость дополнительного железа на BL может многократно превысить стоимость сервера БД, а тут ещё надо учесть что чем больше серверов тем больше елементов которые могут выйти из строя и новые накладные разходы на их сопровождение.
            Но всё это надо воспринимать с долей скепсиса, нет гипотетических приложений, есть реальные с не менее реальными требованиями и когда-то будет лучше один подход когда-то другой, но что вам подойдёт лучше выясните только вы и опираясь на свои требования и ограничения, а не авторов статьи о гипотетической системе.
            Если как написали в одном из коментариев нужно быстрое хранилище, может вообще взять что-то вроде BigTable.
            • +1
              По большей части согласен )

              Вывод — надо думать головой, а не копировать практики )) И тут, думаю, все по-прежнему — хорошего программиста subj заставит задуматься, плохого — ничему хорошему не научит :) No revolution.
  • +3
    классный перевод. понравились картинки.
    но я так и не увидел ответ на главный вопрос жизни, вселенной и всего такого:
    Что такое бизнес логика?
    :)
  • 0
    «в хранимых процедурах бизнес-логика плохо, т.к. в частности, SQL — ограниченный язык».

    Если для процедур используется Java/C/Python, тогда можно бизнес-слой в базе держать?
    Отдельно пакеты для СУПО, отдельно — для бизнеса
    • 0
      Логически — да, фактически — готовьтесь к проблемам с производительностью с некоторого этапа. Если актуально, конечно :)

      P.S. Сам сборки с бизнес-валидацией в MsSql хостю )
  • 0
    Ха-ха! Ну и где ваш PL-SQL теперь?
  • –1
    На мой дилетантский взгляд, главная причина, почему бизнес логика съезжает в среднее звено из базы данных — человеческий фактор. Он затронут в статье, но, ИМХО, акценты расставлены неправильно. Я бы назвал перенос всей бизнес логики в среднее звено: «Победа человеческого фактора над инженерной целесообразностю».
    Главная причина переноса, ИМХО, это разграничение ответственностей разработчиков/администраторов БД.
    Не надо думать, что «Война все спишет», т.е. поставим больше серверов, поднимем каналы потолще, и все будет ОК. Я сам не администратор, а разработчик, но знаю, что сколько не дай разработчикам, им будет все мало. Удобно им раотать со списками в классе — будут тянуть всю таблицу из базы и обрабатывать в классе. Вот и получим, что X*5 оборудования дадут X+0.1*5 прироста возможностей.
    • +2
      Главная причина съезжания нечёткость бизнес логики. Окружающий мир значительно сложнее чем наши упрощённые 2-мерные модели. Возьмём простой пример валидации введённых данных. Даные должны быть проверены в Пользовательском интерфесе, Бизнес слое, Слое доступа к данным, в СУБД, вот и имеем размазанный бизнес слой, а добавьте сюда множество источников данных, явные и неявные ограничения и вся, прокидывание ошибок снизу вверх и назад и вся ваша красивая иерархия начинает рушится как карточный домик. Непонимание и игнорирование этой сложности верный путь получить пулю в висок, это не знаит что разработчик должен сидеть и ничего не делать, а значит что воспринимать любой догмат нужно с долей скепсиса.
      А пример «Удалить покупателя» чесно говоря показывает что автор читал книгу на которую ссылаетя да не дочитал. Во первых уже усть более новая «Microsoft Application Architecture Guide, 2nd Edition». А во вторых удалить покупателя, должно обращатся к DAL (Data Access Layer) слою, а как он сделает это удаление через SP или напрямую DELETE это его проблема. И выносить такое в бизнеслогику на мой взгляд ересь, пусть DAL слой может быть очень тонкой прослойкой вроде ActiveRecord.
      • 0
        Есть еще класс вещей, которые должны быть завернуты в транзакции, и если мы начнем выносить эти вещи из базы в промежуточный слой, то это верный путь к нарушению целостности данных.

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

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

        Получим:
        — слой обращения к данным
        — ясную разработчикам и администраторам БД политику.
        — ясную полиси, мотивирующую к сокращению гоняемых данных.

        Но это конечно интересно для нагруженных масштабируемых систем.
        • 0
          > Многие разработчики просто не умеют и не любят работать с базами и предпочитают тащить все данные в программу и затем уже обрабатывать их в программе.

          Это частично связано с тем что они часто не знают БД в достаточной мере. Я лично когда смотрю на Оракл то у меня складывается впечатление что тут нужно учится очень долго чтобы хотя бы начать. Сложно быть универсальным специалистом во всём. Плюс слабая подготовка по части реляционной алгебры и непонимание между разработчиком БД и разработчиком прилодения, потому что они говорят на разных языках. Тут уже зависит от опыта техлида, который найдёт общий язык с обеими сформулирует ясные требования для обоих и проконтролирует их исполнение. Правда потом ни на что другое времени не остаётся :)
        • 0
          > Я вот задумался,…

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

          Предложеную вами политику на мой взгляд несложно ввести, но вот даст ли она преимущества или нет я не знаю.
          Обычно DAL хотя бы минимальный присутствует и для всех остальных клиентов что там снизу неизвесно. DAL реализирует ограниченое количество разработчиков и договорится что и каким образом делать несложно. Хотя может я проэктирую свой опыт и свои проэкты, где DAL не более 2-х человет плюс один DB-ник не писали.
          У меня сейчас вообще MS SQL CE где нет хранимых процедур :).
          Мой опыт лучше плохое соглашение чем вообще никакого.
          • 0
            Я не предлагаю унисерсальное решение, я так сказать пытаюсь сделать выводы из своего опыта и найти пути преодоления проблем.
            Предлагаемый метод какие проблемы решает:
            — Заставляет разработчика хоть как-то попробовать и понять цели и иснструменты СУБД, чтобы потом не встречать запросы к таблицам типа SELECT * FROM в коде, в поисках что это там так зверски тормозит или все ломается после того, как в таблицу добавили поле.
            — Преодолевает сопротивление администраторов БД.
            — Потенциально убирает административные/человеческие препятствия к написанию эффективного кода.
        • 0
          >>а что если бизнес логику поделить 50/50 (грубо) между базой и промежуточным слоем по следующей схеме: каждый метод, обращающийся к базе должен делать это через только соответствующую встроенную процедуру, пусть даже совсем простую.

          У нас так. Получается херня.
          Over 9000 хранимых процедур (уже перевалило за 600), вперемешку тривиальные и не очень, головняк при сопровождении, постоянные траблы с версиями. Нах такое, короче говоря :)
          • 0
            Контролем версий пользуетесь?
            • 0
              А что это такое? :D

              Конечно, пользуемся. Даже больше — TFS позволяет все скрипт-объекты базы загнать под scm, и дальше каждая правка будет версионироваться. Но только на моей памяти уже было несколько раз такое, что вследствие некорректной работы TFS БД «делала ручкой» и уплывала в непонятном направлении; и только героические усилия команды админов ее спасали :)

              Далее, scm в чистом виде не поможет вам при, например, обновлении у клиента. Нужны миграторы, которые, в принципе, плохо приспособлены для обновления скрипт-объектов типа хранимок-триггеров и т.п… Не, скажу по-другому — люди плохо приспособлены пользоваться миграторами :)

              Кроме того, scm не поможет никак в плане атоматического согласования метаданных — только ручная работа.

              Ну и непонятно, как scm поможет избавиться от 600 хранимок.
      • 0
        Валидация входных данных это отдельный слой, который не относится к слою бизнес-логики. Бизнес-логика это не «логика, как обрабатывать данные», а лишь отдельная ее часть (layer) — абстрактная модель предметной области (domain logic).
  • +1
    Ух! Хабр похоже еще очень даже торт! Спасибо — статью в избранное.
  • 0
    Спорный момент — форматирование телефонного номера. Это не бизнес-логика, это всего-лишь логика представления. А кто говорил что логика представления должна быть простой? :)
  • 0
    хоть что-то полезное на хабре за полгода =;) ретвит

    особенно порадовали микрухи (операционный усилитель?), изображающие проц
    • 0
      уж год как прошёл :)

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