Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 122
Отличная статья! Все проблемы как с нас списаны. Дам прочитать нашему архитектору, будем задумываться о переносе большей части логики с сервера БД на сервер приложений.
Недавно общался с человеком на похожую тему. Распинался о правильном проектировании систем, культуре программирования и т.п. В ответ услышал циничное: «Зачем все это? Как-нибудь слепим, поставим еще 50 серверов и уже начнем зарабатывать деньги, когда ты не выполнишь и половину работы». Так и не нашелся, что сказать в ответ.
любые практики и методики — это всегда сделка, между тем что правильно и тем, что нужно :)
идеальный продукт никому не нужен, и лучший не нужен.
нужен просто хороший
идеальный продукт никому не нужен, и лучший не нужен.
нужен просто хороший
Да это сплошь и рядом!
Руководство интересует только чтобы
а) было сделано быстро
б) работало
Все!
И никого не корябает «правильность» и «красота» реализации.
И их тоже можно понять. Им денег надо заработать а не осчастливить всех вокруг…
Руководство интересует только чтобы
а) было сделано быстро
б) работало
Все!
И никого не корябает «правильность» и «красота» реализации.
И их тоже можно понять. Им денег надо заработать а не осчастливить всех вокруг…
Обычно руководство и не должна интересовать «правильность» хотя бы потому что они компетентны в ток как продать, а как реализировать это не их проблема.
А реализировать «правильно» с твоей точки зрения это твой интерес, чтобы потом 70% времени который отойдёт на сопровождение продукта ты и твои колеги не вспоминали с матами свою расхлябаность.
Привычка писать чисто и не срезать углы это как привычка не мусорить около себя и чистить зубы, обычно это прививается старшими и или более авторитетными разработчиками, а также зависит от принятой культуры разработки, если её не привить вовремя то приходится ходить з делезной линейкой и жестоко отчитывать при каждом код ревью. Ах да, забыл упомянуть у «И никого не корябает «правильность» и «красота» реализации.» обычно нет код ревью даже постфактум.
А реализировать «правильно» с твоей точки зрения это твой интерес, чтобы потом 70% времени который отойдёт на сопровождение продукта ты и твои колеги не вспоминали с матами свою расхлябаность.
Привычка писать чисто и не срезать углы это как привычка не мусорить около себя и чистить зубы, обычно это прививается старшими и или более авторитетными разработчиками, а также зависит от принятой культуры разработки, если её не привить вовремя то приходится ходить з делезной линейкой и жестоко отчитывать при каждом код ревью. Ах да, забыл упомянуть у «И никого не корябает «правильность» и «красота» реализации.» обычно нет код ревью даже постфактум.
Абсолютно точно. Там где на решение «как делать» хоть как-то влияет высокое руководство — там получается то самое «И никого не корябает «правильность» и «красота» реализации».
«код ревью» — таких слов высокое руководство даже не знает. :) Системы самонаводящиеся… «Выстрелил и забыл». То есть «продал и забыл». :)
«код ревью» — таких слов высокое руководство даже не знает. :) Системы самонаводящиеся… «Выстрелил и забыл». То есть «продал и забыл». :)
Не знаю что у вас за руководство. Но система контроля версий, код ревью, обязательный анализ архитектуры кем-то из другого отдела это то что моё руководство делает. Оно может и не обязано понимать технических деталей, но понимает что отдать всё на самотёк это большой риск для проэктов и для компании в целом и в его интересах поставить процес чтобы он был самоисполняющимся и с большой долей вероятности исполнялся в срок и с заданным бюджетом и чтобы инвестиции в системы были не одноразовыми. Если руководство этого не понимает то это бомба с тикающим механизмом. Кстати сейчас в том же офсорсинге каждый заказ я так понимаю на вес золота, потому люди с раздолбайским подходом имеют все шансы занятся другими видами деятельности.
К слову у нас разрабатывается один проэкт с 2001-го года. С C++/MFC/ActiveX/XML последовательно переползли на C#/ActiveX(почти вычистили)/XML и сейчас проэкты созданые для первых версий можно конвертировать. И движок функционирует по той же самой логике которая была создана изначально. В продукт инвестировано несколько десятков милионов долларов и если бы следовали подходу сделать побыстрее и абы как, то деньги давно пришлось бы списать, а ряду руководителей проэкта поискать работу в другой сфере.
К слову у нас разрабатывается один проэкт с 2001-го года. С C++/MFC/ActiveX/XML последовательно переползли на C#/ActiveX(почти вычистили)/XML и сейчас проэкты созданые для первых версий можно конвертировать. И движок функционирует по той же самой логике которая была создана изначально. В продукт инвестировано несколько десятков милионов долларов и если бы следовали подходу сделать побыстрее и абы как, то деньги давно пришлось бы списать, а ряду руководителей проэкта поискать работу в другой сфере.
Правильная организация модели позволяет избежать дублирования. Одно из следствий отсутствия дублирования — более дешевые изменения, что важно для бизнеса. «Правильная» и «красивая» реализация подразумевает то, что проект будет собран весьма быстро и будет подготовлен к неизбежным изменениям. Если объяснять придерживаясь такой позиции, бизнес все прекрасно понимает.
> поставить еще 50 серверов
Да уж, или он ни разу ничего не масштабировал, или это гуру, для которого создавать масштабируемые системы уже давно стало обыденностью.
Да уж, или он ни разу ничего не масштабировал, или это гуру, для которого создавать масштабируемые системы уже давно стало обыденностью.
Да, а потом самое маленькое изменение в этом 'высоко-профессиональном' приложении будет занимать больше, чем переписка всего заново.
С «навороченной» архитектурой — нет, с хорошей архитектурой — да.
Дело не в том чтобы сделать «архитектуру», дело в том чтобы дополнения более-менее придерживались принципа open-closed — то есть можно было бы добавлять новые штуки, почти не меняя старые.
У меня тоже есть опыт работы в проектах для больших компаний. Я видел средние проекты, плохие проекты, и хорошие проекты.
Так вот плохие проекты могут застрять ни на чём на долгое время, а хорошие проекты двигаются вперёд равномерно и довольно неплохо.
Дело не в том чтобы сделать «архитектуру», дело в том чтобы дополнения более-менее придерживались принципа open-closed — то есть можно было бы добавлять новые штуки, почти не меняя старые.
У меня тоже есть опыт работы в проектах для больших компаний. Я видел средние проекты, плохие проекты, и хорошие проекты.
Так вот плохие проекты могут застрять ни на чём на долгое время, а хорошие проекты двигаются вперёд равномерно и довольно неплохо.
Есть гарантии, что в приложении с «правильной» архитектурой изменения обойдутся дешевле. «Правильная» — эта та, которая готова к изменениям и постоянном рефакторингу, тому, что обязательно присутствует в любом живом проекте.
И это — чудесно. Потому что масса народа получит на долгое время высокооплачиваемые рабочие места. Начиная от топовых менеджеров, отвечающих за улучшение и повышение эффективности, заканчивая уборщицами на новый этаж офиса.
Увы, таковы реалии общества потребления. Делать, чтобы было себе, а не миру.
Увы, таковы реалии общества потребления. Делать, чтобы было себе, а не миру.
Я (да в общем и компания где я работаю) никогда не работал с целью создать рабочие места таким образом, и сама идея мне неприятна.
С другой стороны, кто сказал что клиент с таким приложением пойдёт к той же компании, которая его исходно написала? Чаще будет так, что он выслушает estimate и отправится к другим, раз уж всё равно надо переписывать. К индусам или китайцам, например, раз качество всё равно не отличается.
С другой стороны, кто сказал что клиент с таким приложением пойдёт к той же компании, которая его исходно написала? Чаще будет так, что он выслушает estimate и отправится к другим, раз уж всё равно надо переписывать. К индусам или китайцам, например, раз качество всё равно не отличается.
Пропиарились. Почти грамотно (ибо «идея мне неприятна» — несколько эгоцентрично). Здравомыслящий клиент не станет обращаться к тем, кто вместо реализации его идеи — начинает складывать о ней свое мнение. Как правило такие исполнители, если им вдруг что-то «неприятно», начинают делать так, что перестает быть «приятно» клиенту.
«Чаще будет так… » Выши бы слова да топам в уши. Но увы, увы. Топы слушают не естимат, а про откат, либо смотрят красочность презенташек, али еще на некоторые вещи. А нужный естимат легко получается за счет стандартной операции «следущая итерация». Кроме того, в резюме гораздо солиднее смотрится управление сотней человек, чем десятком. Вот и причина, почему раздувают проекты-штаты.
Возвращаясь к статье: я счас заканчиваю работать в проекте, который изначально имеет БЛ в ДБ (Oracle). Руководитель этого проекта поднялся на нем за тройку лет с никого до заместителя вице-президента (надеюсь, вы в курсе, кто такие ВП в крупных международных конторах) со штатом в десяток человек.
«Чаще будет так… » Выши бы слова да топам в уши. Но увы, увы. Топы слушают не естимат, а про откат, либо смотрят красочность презенташек, али еще на некоторые вещи. А нужный естимат легко получается за счет стандартной операции «следущая итерация». Кроме того, в резюме гораздо солиднее смотрится управление сотней человек, чем десятком. Вот и причина, почему раздувают проекты-штаты.
Возвращаясь к статье: я счас заканчиваю работать в проекте, который изначально имеет БЛ в ДБ (Oracle). Руководитель этого проекта поднялся на нем за тройку лет с никого до заместителя вице-президента (надеюсь, вы в курсе, кто такие ВП в крупных международных конторах) со штатом в десяток человек.
Здравомыслящий клиент не станет обращаться к тем, кто вместо реализации его идеи — начинает складывать о ней свое мнение
В самом деле? На самом деле хорошие клиенты, которых я видел, были очень заинтересованы в нашем мнении. Если команда способна понять не только техническую, а бизнес задачу и предложить лучшее решение, это очень ценится разумными клиентами. Конечно, за клиентом всегда последнее слово, и два раза одно и то же не предлагают, поэтому он и не боится слушать.
А идея мне неприятна я говорил об идее писать плохо ради собственной выгоды, которая и клиенту неприятна обычно (если это аутсурсинг, по крайней мере) — они всё-таки хотят верить что технические задачи будут решаться честно.
Топы в разных компаниях разные, но вообще-то все компании-заказчики, которые я до сих пор видел, были довольно экономны (и чем больше компания, тем более мелочной она часто оказывается).
Возвращаясь к статье: я счас заканчиваю работать в проекте, который изначально имеет БЛ в ДБ (Oracle). Руководитель этого проекта поднялся на нем за тройку лет с никого до заместителя вице-президента
Да, потому что проект может быть написан плохо, но всё равно решать все поставленные задачи, или если эстимейты неважны, или всё строго и нельзя заменить поставщика, и во многих других случаях. Может быть он прекрасный руководитель, но плохой архитектор, whatever.
С другой стороны, например, строители у нас строят плохо, а получают сверхприбыли — это тоже пример для подражания?
Перестаньте троллить :)
Конечно исходное приложение быстрее слепить как попало, если оно не сложное.
А вот добавлять новые возможности вы будете быстрее и без того, чтобы всё сломалось.
А вот добавлять новые возможности вы будете быстрее и без того, чтобы всё сломалось.
Это нормально для небольших проектов. Проект который развивается в течении нескольких лет с таким подходом либо скоро загнётся, либо станет нерентабельным, либо вынужденно будет перепроектирован. Совершенно согласен с автором статьи: база данных должна заниматься только СУПОм и бизнес логику дешевле держать на сервере. А ещё моё личное мнение, что работать со списками гораздо удобней из какого-нибудь языка C#, C++, python, etc., чем из хранимых процедур. И вообще SQL как язык удобен только для консоли, в программировании он не нужен.
P.S. На холиварные комментарии отвечать не собираюсь. Этот комментарий моё личное мнение.
P.S. На холиварные комментарии отвечать не собираюсь. Этот комментарий моё личное мнение.
А ещё моё личное мнение, что работать со списками гораздо удобней из какого-нибудь языка C#, C++, python, etc., чем из хранимых процедур.
Ну так для этого и были добавлены Java в Oracle, Tcl, Python, Perl в PostgreSQL и т.д.
Я вот тоже слегка удивился тому, что автор с уверенностью(и знанием дела, наверное) говорит о том, что у очень многих даже сейчас бизнес-логика в хранимых процедурах. Может это, конечно, где-то там… в «энтерпрайзе».
Для меня БД это просто хранилище для объёктов, которое умеет считать минимальные какие-то вещи вроде кол-ва, максимума\минимума и т.п.
Для меня БД это просто хранилище для объёктов, которое умеет считать минимальные какие-то вещи вроде кол-ва, максимума\минимума и т.п.
Затем, что далеко не всегда всё решается увеличением числа серверов и их мощностей.
И рано или поздно, как правило, наступает момент, когда новые сервера не помогают, потому что архитектура-то кривая. И иногда, если сразу не подумать, то рефакторинг может очень дорого обойтись…
Ну и зачем нагружать 50 серверов, если с этим легко могут справиться, скажем 10?
Но сталкиваться с таким приходится…
И рано или поздно, как правило, наступает момент, когда новые сервера не помогают, потому что архитектура-то кривая. И иногда, если сразу не подумать, то рефакторинг может очень дорого обойтись…
Ну и зачем нагружать 50 серверов, если с этим легко могут справиться, скажем 10?
Но сталкиваться с таким приходится…
Все правильно написано. Один момент — это применимо только к domain-centric модели в n-tier. В случае, если используется REST-like модель, зачастую желательно business-layer поджимать или к одной, или к другой стороне, убирая ее с шлюза данных.
Еще один момент (распространненная ошибка) — разрывать business logic layer и data access layer, зачастую на разные машины, чтобы потом героическими темпами по выстругиванию костылей решать эти трудности типа «отсутствующие данные» или «полбазы вынули на запрос» с БД на business layer.
Еще один момент (распространненная ошибка) — разрывать business logic layer и data access layer, зачастую на разные машины, чтобы потом героическими темпами по выстругиванию костылей решать эти трудности типа «отсутствующие данные» или «полбазы вынули на запрос» с БД на business layer.
Статья устарела
Сейчас перспектива — облако
Сейчас перспектива — облако
> В какой блог поместить?
Предлагаю Проектирование и рефакторинг, т.к. большая часть статьи описывает один из шаблонов проектирования. Плюс небольшие забавные отступления про переубеждение строгих администраторов баз данных можно с натяжкой отнести к рефакторингу.
Концентрация бизнес-логики в среднем слое наиболее логичное решение и, пожалуй, это первое что приходит в голову. Об этом же ратует архитектура MVC, близкая веб-разработчикам: данные отдельно, представление (здесь клиент или веб-клиент) отдельно, а посерединке контроллер или бизнес-логика. Проблема в том, что в чистом виде это не работает. Слишком часто приходится допускать исключения: со стороны клиента исключить заранее известные невалидные или слишком типичные запросы, со стороны сервера постараться не тягать гигабайты промежуточной информации. А это уже рассредотачивание логики (пусть даже это и дублирование, все-равно при изменении правила придется редактировать сразу в двух местах). Плюс сюда довольно расплывчатое определение, что является бизнес-логикой — и вместо слоя с четкими очертаниями получается нечто дымчатое.
Про стоимость железа интересно, в этом плане даже не задумывался.
Предлагаю Проектирование и рефакторинг, т.к. большая часть статьи описывает один из шаблонов проектирования. Плюс небольшие забавные отступления про переубеждение строгих администраторов баз данных можно с натяжкой отнести к рефакторингу.
Концентрация бизнес-логики в среднем слое наиболее логичное решение и, пожалуй, это первое что приходит в голову. Об этом же ратует архитектура MVC, близкая веб-разработчикам: данные отдельно, представление (здесь клиент или веб-клиент) отдельно, а посерединке контроллер или бизнес-логика. Проблема в том, что в чистом виде это не работает. Слишком часто приходится допускать исключения: со стороны клиента исключить заранее известные невалидные или слишком типичные запросы, со стороны сервера постараться не тягать гигабайты промежуточной информации. А это уже рассредотачивание логики (пусть даже это и дублирование, все-равно при изменении правила придется редактировать сразу в двух местах). Плюс сюда довольно расплывчатое определение, что является бизнес-логикой — и вместо слоя с четкими очертаниями получается нечто дымчатое.
Про стоимость железа интересно, в этом плане даже не задумывался.
Первая вразумительная статья по противостоянии двухзвенки и трехзвенки. Спасибо, очень интересно.
Обертка, обертка, ...., обертка…
Парень люди хотят конфету. Берут они конфету, а обертку выбрасывают. И только у вкусных конфет, они разглядывают фантик.
Парень люди хотят конфету. Берут они конфету, а обертку выбрасывают. И только у вкусных конфет, они разглядывают фантик.
*Не туда вписал.
А кто автор?
А кто автор?
там как бы написано
Chad Z. Hower aka Kudzu
Chad Z. Hower aka Kudzu
В теле статьи не было!? Создает проблемы в восприятии. Может следовало бы в начальном абзаце отдельно представить, если дается перевод.
habrahabr.ru/info/help/ — всем новичкам рекомендуется к прочтению
это утверждение верно для большей части ресурсов
это утверждение верно для большей части ресурсов
дефис, блять, дефис надо ставить в составных словах, где «бизнес» является первой его частью!
что, стыдно?
А за что стыдится. Это вам с вашим лексикой место на других сайтах. Если есть ошибка можете послать личное сообщение автору и я уверен он вас поблагодарит и исправит. Также вы могли написать коментарий но без б… который тоже бы учли.
Здесь комюнити технарей, а не грамотеев. Лично для меня русский неродной и я на нём почти не говорю и считаю нормальным ошибатся и исправлять потом свои ошибки. А грубиянов не люблю, судя по минусам не один я такой.
Здесь комюнити технарей, а не грамотеев. Лично для меня русский неродной и я на нём почти не говорю и считаю нормальным ошибатся и исправлять потом свои ошибки. А грубиянов не люблю, судя по минусам не один я такой.
Автор не слышал о бесплатных базах данных?
Видел несколько проектов, в который декларировался принцип — «Вся логика в базу».
Вне базы были собственно только шаблоны для генерации html и контроллеры на 3-5 строк.
Сам успешно их критиковал поначалу. А потом подумал — а ведь они же работают. И это самое главное.
А бывает еще, когда в принципы разработки приложения включается «Do it as fast as possible». В этом случае database views очень хорошо экономят время.
Видел несколько проектов, в который декларировался принцип — «Вся логика в базу».
Вне базы были собственно только шаблоны для генерации html и контроллеры на 3-5 строк.
Сам успешно их критиковал поначалу. А потом подумал — а ведь они же работают. И это самое главное.
А бывает еще, когда в принципы разработки приложения включается «Do it as fast as possible». В этом случае database views очень хорошо экономят время.
То есть быстрее написать логику на SP в MySQL, чем на нормальном языке?
А если нужна одна и та же логика для многих сущностей?
Вообще процедурное программирование живёт до какого-то уровня сложности, но я бы не сказал что оно проще, особенно на ограниченном языке типа SQL.
А если нужна одна и та же логика для многих сущностей?
Вообще процедурное программирование живёт до какого-то уровня сложности, но я бы не сказал что оно проще, особенно на ограниченном языке типа SQL.
Спасибо автору. Очень качественный материал.
Грамотно расставлены акценты на системы и на людей.
Видимо основные проблемы долгоживущих бизнес систем связаны с фактором «так исторически сложилось».
Отсутствие такой штуки как Process Improvement по широкому кругу вопросов от реализации процедур обработки бизнес-логики до предполагаемых расходов и рисков, связанных с ростом системы и внедрением в неё новых компонет пожалуй является основой того, что админы БД и манагеры бояться изменений архитектуры, как огня.
А на счёт того, что безопопасней — регулировать права доступа на много модульных систем бизнес-логики промежуточного слоя или правами к одной большой СУБД, пусть даже по отдельным базам и таблицам, нужно всегда смотреть в каждом конкретном случае.
Грамотно расставлены акценты на системы и на людей.
Видимо основные проблемы долгоживущих бизнес систем связаны с фактором «так исторически сложилось».
Отсутствие такой штуки как Process Improvement по широкому кругу вопросов от реализации процедур обработки бизнес-логики до предполагаемых расходов и рисков, связанных с ростом системы и внедрением в неё новых компонет пожалуй является основой того, что админы БД и манагеры бояться изменений архитектуры, как огня.
А на счёт того, что безопопасней — регулировать права доступа на много модульных систем бизнес-логики промежуточного слоя или правами к одной большой СУБД, пусть даже по отдельным базам и таблицам, нужно всегда смотреть в каждом конкретном случае.
Отличная статья! Есть кое-какие огрехи перевода, но все равно ставлю плюсы везде, где могу :)
Читал статью и был немного не согласен, но слова про «дублирование немножко бизнес-логики на клиенте и в БД», меня добили и обратили в Вашу веру. Впереди есть очень забавный проект, будем сопротивляться дивному желанию засунуть всего и побольше в хранимки. Хотя, пожалуй, тут тоже надо посидеть, пока есть время и «поиграться».
По-моему, суть статьи можно выразить шестью словами: «Не используй хранимые процедуры, кроме вьюшек!»
В такой форме можно добавлять эту статью к разным там «10 заповедей программиста» ;)
В такой форме можно добавлять эту статью к разным там «10 заповедей программиста» ;)
Допустим необходимо разработать отчет, где реализовывать код на стороне клиента или на стороне сервера приложений?
умоляю, поставьте дефис в заголовке.
На самом деле, базе данных становится не очень хорошо от слишком большого количества загруженных хранимых процедур
Интересно, на чем основано данное утверждение?
Вообще почти все доводы автора по поводу снижения производительности системы при использовании ХП для меня звучат не очень убедительно. ИМХО перенос бизнес-логики ближе к данным как раз увеличивает производительность системы снижая расходы на передачу промежуточных данных и их преобразования из объектной модели в реляционную и обратно.
Вы все правильно говорите — необходимо стремиться к наибольшей локальности данных и кода, работающего с ними — это тоже можно считать одной из «заповедей» :)
Проблема в том, что а) это стремление — не единственный критерий, который нужно учитывать б) попытка соблюдать данную «заповедь» во что бы то ни стало похерила не один проект; по правде говоря, это стремление херит проекты гораздо чаще, чем излишнее распределение — я думаю, любой читающий и пишуший здесь в своей жизни видел тонны write-only бизнес-логики, накрученной в SQL.
Автор просит руководствоваться здравым смыслом в первую очередь, и не доводить до фанатизма с одной стороны и «я все знаю и так» — с другой, а решать объективно.
Проблема в том, что а) это стремление — не единственный критерий, который нужно учитывать б) попытка соблюдать данную «заповедь» во что бы то ни стало похерила не один проект; по правде говоря, это стремление херит проекты гораздо чаще, чем излишнее распределение — я думаю, любой читающий и пишуший здесь в своей жизни видел тонны write-only бизнес-логики, накрученной в SQL.
Автор просит руководствоваться здравым смыслом в первую очередь, и не доводить до фанатизма с одной стороны и «я все знаю и так» — с другой, а решать объективно.
Согласен с каждым вашим словом. Но, в отличии от Вас, у автора как-то уж сильно однобоко получилось в сторону того, что хранимые процедуры — зло.
имхо смысл статьи вовсе не в «бизнес-логике», а в том, что:
что вполне логично, для Micro$oft. :)
среднее звено имеет емкость для роста и гораздо дешевле базы данных
что вполне логично, для Micro$oft. :)
А можете пояснить, при чем здесь MS? Дело в том, что объективен тот факт, что кластеризовать сервер приложений куда проще, чем БД; и у всех производителей решение виртуализации БД стоит куда дороже, чем средство балансирования нагрузки между узлами с серверами приложений.
для Оракл и Сана тоже ;)
Замечательная статья, разослал ссылки коллегам разработчикам.
Кстати, по поводу хранимок — это отдельная песня; в настоящее время большинство разработчиков склоняются к мысли, что они приемлемы в 2х случаях:
а) легаси система, когда все работает и нет смысла переделывать
б) когда БД в проекте занимается специальный выделенный отдел DBA — в таком случае со стороны БД необходимо выставить некоторую поверхность Business API, ее роль как раз и играет набор stor-proces и view.
В остальных случаях такие недостатки, как проблемы с версионированием, обновлением и кросс-платформенностью полностью перечеркивают почти полностью исчезнувшие на данный момент плюсы хранимок, такие, как скорость выполнения, повышенная безопасность и разграничение доступа.
Еще один тип проблем — SQL своей ограниченностью подталкивает на реализацию в хранимках «финтов ушами» типа динамического SQL, своих xml-парсеров, хранение текстовых констант и шаблонов для UI прямо там и т.п.
а) легаси система, когда все работает и нет смысла переделывать
б) когда БД в проекте занимается специальный выделенный отдел DBA — в таком случае со стороны БД необходимо выставить некоторую поверхность Business API, ее роль как раз и играет набор stor-proces и view.
В остальных случаях такие недостатки, как проблемы с версионированием, обновлением и кросс-платформенностью полностью перечеркивают почти полностью исчезнувшие на данный момент плюсы хранимок, такие, как скорость выполнения, повышенная безопасность и разграничение доступа.
Еще один тип проблем — SQL своей ограниченностью подталкивает на реализацию в хранимках «финтов ушами» типа динамического SQL, своих xml-парсеров, хранение текстовых констант и шаблонов для UI прямо там и т.п.
Большое спасибо за статью.
Можно небольшое замечание по переводу? Lord (именно с большой буквы) — это Бог, а не лорд.
dictionary.reference.com/browse/Lord?r=75&src=ref&ch=dic
Можно небольшое замечание по переводу? Lord (именно с большой буквы) — это Бог, а не лорд.
dictionary.reference.com/browse/Lord?r=75&src=ref&ch=dic
похоже на правду. автор местами путается при использовании терминов layer и tier.
статья как раз о том, что сервер БД пора перестать рассматривать как многоцелевой компонент. сервер БД — это просто шустрое хранилище.
Люди которые мыслят чёрнобелымы категориями обычно ничего хорошего написать не могут. Никому не нужна идеальная система которая никогда не будет написана. Окружающий мир значительно сложнее. И если SQL Server оброс функциями app server это не потому что так маркетологу захотелось, а потому что многим заказчикам это действительно нужно и этим пользуются.
И вдогонку. Я категорически неприемлю подход в котором бизнес слой должен знать больше чем должен о слое БД. Это противоричит идее инкапсуляции. Как раз хорошо когда БД самостоятельно на основе своей структуры произведёт изменение учитывая ограничения, а код бизнеслоя должен думать как исполнить свой контракт и при выполнении транзакции сохранить соглазованость и непротиворечивость даных именно своего слоя.
Да размазано частично получается но с другой стороны, с какого такого Бизнес слой должен знать как хранятся данные.
Да размазано частично получается но с другой стороны, с какого такого Бизнес слой должен знать как хранятся данные.
>> размазано частично
Это про ваш комментарий, вестимо, уж извините. Если не сложно, поясните, пожалуйста, следующее:
>>знать больше чем должен о слое БД
А что он должен знать?
>>Это противоричит идее инкапсуляции
Сам подход Фон-Неймана хранить данные и программу в одной памяти противоречит «абстрактным» принципам инкапсуляции, на которые вы ссылаетесь. Что понимается под инкапсуляцией в вашем примере? Что от чего вы собираетесь изолировать?
>>с какого такого Бизнес слой должен знать как хранятся данные.
Весь бизнес-слой — не должен. Должна знать его часть, называемая Repository или Data Access. На этом построена целая технология ORM.
Иначе, если следовать вашему пониманию, и sql в бизнес-логике недопустим.
Имхо, вы не понимаете, что вы пишете.
Это про ваш комментарий, вестимо, уж извините. Если не сложно, поясните, пожалуйста, следующее:
>>знать больше чем должен о слое БД
А что он должен знать?
>>Это противоричит идее инкапсуляции
Сам подход Фон-Неймана хранить данные и программу в одной памяти противоречит «абстрактным» принципам инкапсуляции, на которые вы ссылаетесь. Что понимается под инкапсуляцией в вашем примере? Что от чего вы собираетесь изолировать?
>>с какого такого Бизнес слой должен знать как хранятся данные.
Весь бизнес-слой — не должен. Должна знать его часть, называемая Repository или Data Access. На этом построена целая технология ORM.
Иначе, если следовать вашему пониманию, и sql в бизнес-логике недопустим.
Имхо, вы не понимаете, что вы пишете.
> Имхо, вы не понимаете, что вы пишете.
Боюсь это не я не понимаю, а автор статьи со своим примером «Удалить покупателя». Идиоту ясно что в приедённом примере нужен DAL слой, да и в книге на которую он ссылается это есть. А как DAL реализируют, какой ORM будет использован это его проблемы и какой там шаблон буде использован AR, Repository или что-то ещё для BL важно только с точки зрения интерфейса взаимодействия явного и неявного контракта.
В этой статье с претензией на монументальность смешались в кучу люди, кони. Вот новичёк прочитает и начнёт лепить положившись на авторитет Хабрахабра.
Вот за это люблю rsdn. Там такое не пропустят редакторы.
Боюсь это не я не понимаю, а автор статьи со своим примером «Удалить покупателя». Идиоту ясно что в приедённом примере нужен DAL слой, да и в книге на которую он ссылается это есть. А как DAL реализируют, какой ORM будет использован это его проблемы и какой там шаблон буде использован AR, Repository или что-то ещё для BL важно только с точки зрения интерфейса взаимодействия явного и неявного контракта.
В этой статье с претензией на монументальность смешались в кучу люди, кони. Вот новичёк прочитает и начнёт лепить положившись на авторитет Хабрахабра.
Вот за это люблю rsdn. Там такое не пропустят редакторы.
Ага, вот теперь понял :)
Не принимайте примеры близко к сердцу. Несомненно, в этой статье, как и в других, есть косяки в деталях. Но она преследует благородную цель — заставить людей думать, что они делают, и ценна хотя бы этим :)
Не принимайте примеры близко к сердцу. Несомненно, в этой статье, как и в других, есть косяки в деталях. Но она преследует благородную цель — заставить людей думать, что они делают, и ценна хотя бы этим :)
Кстати у МС-а давно есть более монументальный и новый труд «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
И всё воспринимать с извесной делей скепсиса :)
А ещё есть набор хорошых видео и объяснений на кодеплексе:
«How To: Design Business Components» apparch.codeplex.com/Wiki/View.aspx?title=How%20To%20-%20Design%20Business%20Components
И всё воспринимать с извесной делей скепсиса :)
Ага, читал. Труды, конечно, фундаментальные, почти в стиле ALT.NET, особенно первый, но не понравилось ни то ни другое — индусы не могут нормально делать :) Видимо, слишком много скепсиса приложил ))
Ну мне помогало по крайней мере чтобы понять почему и как слои должны взаимодействовать с собой. Там всё очень укрупнено.
Нужно учитывать что на архитектуру очень часто накладывает отпечаток технологии какие вы используете, часто они принуждают писать в определённом стиле, например блоки из Enterprise Library или Prism.
Нужно учитывать что на архитектуру очень часто накладывает отпечаток технологии какие вы используете, часто они принуждают писать в определённом стиле, например блоки из Enterprise Library или Prism.
бизнес слой и не должен знать о структуре данных — об этом должен знать data access layer
а в целом надо плясать от задачи, потребностей и возможностей
здравый смысл рулит всегда
а в целом надо плясать от задачи, потребностей и возможностей
здравый смысл рулит всегда
Комментарий ни о чем. Куча общих слов. Замените «написана» и «SQL Server» на что угодно, и получится годный наброс :)
Я объяснил свои коментарии ниже. А человек который лезет в БД с DELETE без крайней нужды или не очень компетентен или БД ограничена (я например сейчас работаю с MS SQL CE где нет Stored Procedures).
Найти несуществующую проблему и потом её решить это верх мастерства.
Приведённый пример «Удалить покупателя» некоректен потому что там SP должна вызыватся из DAL слоя.
А из наличных у меня математиков они где-то з 20-й итерации приблизятся к эфективности реализации операций базовой обработки данных к БД что говорить о обычных програмистах которые quicksort не всегда могут правильно реализировать(а если ечесть сколько есть её модификаций). То что лучше всего делается в БД часто стоит делать именно в БД. Разница в производительности твоего кода и обработки в БД может достигать двох-трёх порядков, только за счёт ненужности прогонки данных меж приложением и БД. И приведённые цыфры добавленых лицензий на SQL могут окупиться, потому что если учесть накладные затраты на извлечение и обработку данных, несовершенство и неоптимизированость вашего кода, то стоимость дополнительного железа на BL может многократно превысить стоимость сервера БД, а тут ещё надо учесть что чем больше серверов тем больше елементов которые могут выйти из строя и новые накладные разходы на их сопровождение.
Но всё это надо воспринимать с долей скепсиса, нет гипотетических приложений, есть реальные с не менее реальными требованиями и когда-то будет лучше один подход когда-то другой, но что вам подойдёт лучше выясните только вы и опираясь на свои требования и ограничения, а не авторов статьи о гипотетической системе.
Если как написали в одном из коментариев нужно быстрое хранилище, может вообще взять что-то вроде BigTable.
Найти несуществующую проблему и потом её решить это верх мастерства.
Приведённый пример «Удалить покупателя» некоректен потому что там SP должна вызыватся из DAL слоя.
А из наличных у меня математиков они где-то з 20-й итерации приблизятся к эфективности реализации операций базовой обработки данных к БД что говорить о обычных програмистах которые quicksort не всегда могут правильно реализировать(а если ечесть сколько есть её модификаций). То что лучше всего делается в БД часто стоит делать именно в БД. Разница в производительности твоего кода и обработки в БД может достигать двох-трёх порядков, только за счёт ненужности прогонки данных меж приложением и БД. И приведённые цыфры добавленых лицензий на SQL могут окупиться, потому что если учесть накладные затраты на извлечение и обработку данных, несовершенство и неоптимизированость вашего кода, то стоимость дополнительного железа на BL может многократно превысить стоимость сервера БД, а тут ещё надо учесть что чем больше серверов тем больше елементов которые могут выйти из строя и новые накладные разходы на их сопровождение.
Но всё это надо воспринимать с долей скепсиса, нет гипотетических приложений, есть реальные с не менее реальными требованиями и когда-то будет лучше один подход когда-то другой, но что вам подойдёт лучше выясните только вы и опираясь на свои требования и ограничения, а не авторов статьи о гипотетической системе.
Если как написали в одном из коментариев нужно быстрое хранилище, может вообще взять что-то вроде BigTable.
классный перевод. понравились картинки.
но я так и не увидел ответ на главный вопрос жизни, вселенной и всего такого:
но я так и не увидел ответ на главный вопрос жизни, вселенной и всего такого:
Что такое бизнес логика?:)
«в хранимых процедурах бизнес-логика плохо, т.к. в частности, SQL — ограниченный язык».
Если для процедур используется Java/C/Python, тогда можно бизнес-слой в базе держать?
Отдельно пакеты для СУПО, отдельно — для бизнеса
Если для процедур используется Java/C/Python, тогда можно бизнес-слой в базе держать?
Отдельно пакеты для СУПО, отдельно — для бизнеса
Ха-ха! Ну и где ваш PL-SQL теперь?
На мой дилетантский взгляд, главная причина, почему бизнес логика съезжает в среднее звено из базы данных — человеческий фактор. Он затронут в статье, но, ИМХО, акценты расставлены неправильно. Я бы назвал перенос всей бизнес логики в среднее звено: «Победа человеческого фактора над инженерной целесообразностю».
Главная причина переноса, ИМХО, это разграничение ответственностей разработчиков/администраторов БД.
Не надо думать, что «Война все спишет», т.е. поставим больше серверов, поднимем каналы потолще, и все будет ОК. Я сам не администратор, а разработчик, но знаю, что сколько не дай разработчикам, им будет все мало. Удобно им раотать со списками в классе — будут тянуть всю таблицу из базы и обрабатывать в классе. Вот и получим, что X*5 оборудования дадут X+0.1*5 прироста возможностей.
Главная причина переноса, ИМХО, это разграничение ответственностей разработчиков/администраторов БД.
Не надо думать, что «Война все спишет», т.е. поставим больше серверов, поднимем каналы потолще, и все будет ОК. Я сам не администратор, а разработчик, но знаю, что сколько не дай разработчикам, им будет все мало. Удобно им раотать со списками в классе — будут тянуть всю таблицу из базы и обрабатывать в классе. Вот и получим, что X*5 оборудования дадут X+0.1*5 прироста возможностей.
Главная причина съезжания нечёткость бизнес логики. Окружающий мир значительно сложнее чем наши упрощённые 2-мерные модели. Возьмём простой пример валидации введённых данных. Даные должны быть проверены в Пользовательском интерфесе, Бизнес слое, Слое доступа к данным, в СУБД, вот и имеем размазанный бизнес слой, а добавьте сюда множество источников данных, явные и неявные ограничения и вся, прокидывание ошибок снизу вверх и назад и вся ваша красивая иерархия начинает рушится как карточный домик. Непонимание и игнорирование этой сложности верный путь получить пулю в висок, это не знаит что разработчик должен сидеть и ничего не делать, а значит что воспринимать любой догмат нужно с долей скепсиса.
А пример «Удалить покупателя» чесно говоря показывает что автор читал книгу на которую ссылаетя да не дочитал. Во первых уже усть более новая «Microsoft Application Architecture Guide, 2nd Edition». А во вторых удалить покупателя, должно обращатся к DAL (Data Access Layer) слою, а как он сделает это удаление через SP или напрямую DELETE это его проблема. И выносить такое в бизнеслогику на мой взгляд ересь, пусть DAL слой может быть очень тонкой прослойкой вроде ActiveRecord.
А пример «Удалить покупателя» чесно говоря показывает что автор читал книгу на которую ссылаетя да не дочитал. Во первых уже усть более новая «Microsoft Application Architecture Guide, 2nd Edition». А во вторых удалить покупателя, должно обращатся к DAL (Data Access Layer) слою, а как он сделает это удаление через SP или напрямую DELETE это его проблема. И выносить такое в бизнеслогику на мой взгляд ересь, пусть DAL слой может быть очень тонкой прослойкой вроде ActiveRecord.
Есть еще класс вещей, которые должны быть завернуты в транзакции, и если мы начнем выносить эти вещи из базы в промежуточный слой, то это верный путь к нарушению целостности данных.
С людьми есть еще вот какой дополнительный нюанс. Многие разработчики просто не умеют и не любят работать с базами и предпочитают тащить все данные в программу и затем уже обрабатывать их в программе. Потом получаются приложения и фреймворки, которые на каждый чих делают по 50 отдельных запросов. А потом удивляемся что получилась практически не масштабируемая система.
Я вот задумался, а что если бизнес логику поделить 50/50 (грубо) между базой и промежуточным слоем по следующей схеме: каждый метод, обращающийся к базе должен делать это через только соответствующую встроенную процедуру, пусть даже совсем простую. Порядок поддерживать при помощи полиси/соглашения по именам. За нарушение полиси драть нещадно.
Получим:
— слой обращения к данным
— ясную разработчикам и администраторам БД политику.
— ясную полиси, мотивирующую к сокращению гоняемых данных.
Но это конечно интересно для нагруженных масштабируемых систем.
С людьми есть еще вот какой дополнительный нюанс. Многие разработчики просто не умеют и не любят работать с базами и предпочитают тащить все данные в программу и затем уже обрабатывать их в программе. Потом получаются приложения и фреймворки, которые на каждый чих делают по 50 отдельных запросов. А потом удивляемся что получилась практически не масштабируемая система.
Я вот задумался, а что если бизнес логику поделить 50/50 (грубо) между базой и промежуточным слоем по следующей схеме: каждый метод, обращающийся к базе должен делать это через только соответствующую встроенную процедуру, пусть даже совсем простую. Порядок поддерживать при помощи полиси/соглашения по именам. За нарушение полиси драть нещадно.
Получим:
— слой обращения к данным
— ясную разработчикам и администраторам БД политику.
— ясную полиси, мотивирующую к сокращению гоняемых данных.
Но это конечно интересно для нагруженных масштабируемых систем.
> Многие разработчики просто не умеют и не любят работать с базами и предпочитают тащить все данные в программу и затем уже обрабатывать их в программе.
Это частично связано с тем что они часто не знают БД в достаточной мере. Я лично когда смотрю на Оракл то у меня складывается впечатление что тут нужно учится очень долго чтобы хотя бы начать. Сложно быть универсальным специалистом во всём. Плюс слабая подготовка по части реляционной алгебры и непонимание между разработчиком БД и разработчиком прилодения, потому что они говорят на разных языках. Тут уже зависит от опыта техлида, который найдёт общий язык с обеими сформулирует ясные требования для обоих и проконтролирует их исполнение. Правда потом ни на что другое времени не остаётся :)
Это частично связано с тем что они часто не знают БД в достаточной мере. Я лично когда смотрю на Оракл то у меня складывается впечатление что тут нужно учится очень долго чтобы хотя бы начать. Сложно быть универсальным специалистом во всём. Плюс слабая подготовка по части реляционной алгебры и непонимание между разработчиком БД и разработчиком прилодения, потому что они говорят на разных языках. Тут уже зависит от опыта техлида, который найдёт общий язык с обеими сформулирует ясные требования для обоих и проконтролирует их исполнение. Правда потом ни на что другое времени не остаётся :)
> Я вот задумался,…
Я не сильно любитель абсолютно универсальных решений, потому что часто они абсолютно неприменимы в реальных условиях.
Предложеную вами политику на мой взгляд несложно ввести, но вот даст ли она преимущества или нет я не знаю.
Обычно DAL хотя бы минимальный присутствует и для всех остальных клиентов что там снизу неизвесно. DAL реализирует ограниченое количество разработчиков и договорится что и каким образом делать несложно. Хотя может я проэктирую свой опыт и свои проэкты, где DAL не более 2-х человет плюс один DB-ник не писали.
У меня сейчас вообще MS SQL CE где нет хранимых процедур :).
Мой опыт лучше плохое соглашение чем вообще никакого.
Я не сильно любитель абсолютно универсальных решений, потому что часто они абсолютно неприменимы в реальных условиях.
Предложеную вами политику на мой взгляд несложно ввести, но вот даст ли она преимущества или нет я не знаю.
Обычно DAL хотя бы минимальный присутствует и для всех остальных клиентов что там снизу неизвесно. DAL реализирует ограниченое количество разработчиков и договорится что и каким образом делать несложно. Хотя может я проэктирую свой опыт и свои проэкты, где DAL не более 2-х человет плюс один DB-ник не писали.
У меня сейчас вообще MS SQL CE где нет хранимых процедур :).
Мой опыт лучше плохое соглашение чем вообще никакого.
Я не предлагаю унисерсальное решение, я так сказать пытаюсь сделать выводы из своего опыта и найти пути преодоления проблем.
Предлагаемый метод какие проблемы решает:
— Заставляет разработчика хоть как-то попробовать и понять цели и иснструменты СУБД, чтобы потом не встречать запросы к таблицам типа SELECT * FROM в коде, в поисках что это там так зверски тормозит или все ломается после того, как в таблицу добавили поле.
— Преодолевает сопротивление администраторов БД.
— Потенциально убирает административные/человеческие препятствия к написанию эффективного кода.
Предлагаемый метод какие проблемы решает:
— Заставляет разработчика хоть как-то попробовать и понять цели и иснструменты СУБД, чтобы потом не встречать запросы к таблицам типа SELECT * FROM в коде, в поисках что это там так зверски тормозит или все ломается после того, как в таблицу добавили поле.
— Преодолевает сопротивление администраторов БД.
— Потенциально убирает административные/человеческие препятствия к написанию эффективного кода.
>>а что если бизнес логику поделить 50/50 (грубо) между базой и промежуточным слоем по следующей схеме: каждый метод, обращающийся к базе должен делать это через только соответствующую встроенную процедуру, пусть даже совсем простую.
У нас так. Получается херня.
Over 9000 хранимых процедур (уже перевалило за 600), вперемешку тривиальные и не очень, головняк при сопровождении, постоянные траблы с версиями. Нах такое, короче говоря :)
У нас так. Получается херня.
Over 9000 хранимых процедур (уже перевалило за 600), вперемешку тривиальные и не очень, головняк при сопровождении, постоянные траблы с версиями. Нах такое, короче говоря :)
Контролем версий пользуетесь?
А что это такое? :D
Конечно, пользуемся. Даже больше — TFS позволяет все скрипт-объекты базы загнать под scm, и дальше каждая правка будет версионироваться. Но только на моей памяти уже было несколько раз такое, что вследствие некорректной работы TFS БД «делала ручкой» и уплывала в непонятном направлении; и только героические усилия команды админов ее спасали :)
Далее, scm в чистом виде не поможет вам при, например, обновлении у клиента. Нужны миграторы, которые, в принципе, плохо приспособлены для обновления скрипт-объектов типа хранимок-триггеров и т.п… Не, скажу по-другому — люди плохо приспособлены пользоваться миграторами :)
Кроме того, scm не поможет никак в плане атоматического согласования метаданных — только ручная работа.
Ну и непонятно, как scm поможет избавиться от 600 хранимок.
Конечно, пользуемся. Даже больше — TFS позволяет все скрипт-объекты базы загнать под scm, и дальше каждая правка будет версионироваться. Но только на моей памяти уже было несколько раз такое, что вследствие некорректной работы TFS БД «делала ручкой» и уплывала в непонятном направлении; и только героические усилия команды админов ее спасали :)
Далее, scm в чистом виде не поможет вам при, например, обновлении у клиента. Нужны миграторы, которые, в принципе, плохо приспособлены для обновления скрипт-объектов типа хранимок-триггеров и т.п… Не, скажу по-другому — люди плохо приспособлены пользоваться миграторами :)
Кроме того, scm не поможет никак в плане атоматического согласования метаданных — только ручная работа.
Ну и непонятно, как scm поможет избавиться от 600 хранимок.
Валидация входных данных это отдельный слой, который не относится к слою бизнес-логики. Бизнес-логика это не «логика, как обрабатывать данные», а лишь отдельная ее часть (layer) — абстрактная модель предметной области (domain logic).
Ух! Хабр похоже еще очень даже торт! Спасибо — статью в избранное.
Спорный момент — форматирование телефонного номера. Это не бизнес-логика, это всего-лишь логика представления. А кто говорил что логика представления должна быть простой? :)
хоть что-то полезное на хабре за полгода =;) ретвит
особенно порадовали микрухи (операционный усилитель?), изображающие проц
особенно порадовали микрухи (операционный усилитель?), изображающие проц
Не надо переводить дословно английские термины. СУПО звучит дико, все привыкли к CRUD и на взгляд и на вид лучше смотрится, если хочется перевести, то можете в скобках написать русский перевод
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Где наша бизнес-логика, сынок?