ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Где должна лежать бизнес-логика в мнгоуровневом приложении
25 сообщений из 318, страница 1 из 13
  1  все
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36438753
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
Хотелось бы услышать мнение сообщества, а не навязывать свое, т.к. свое вызывает у меня некоторые неприятные подозрения. :)

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

В общем что-то такое этакое весьма часто встречающееся.

Для затравки я попробую выступить от имени сторонника хранения бизнес-правил в основном в СУБД, для чего процитирую свое же сообщение с другого форума (только кусок, а то и так много букв):
1. Ценность данных во много раз превосходит ценность софта, включая и вид СУБД, но последняя кардинально обновляется гораздо реже, чем прикладной софт.
Поэтому логично чтобы за их целостность и не противоречивость отвечала СУБД, как:
- менее подверженный изменениям софт

- как специализированный на работе с данными софт, имеющий максимально заточенные для этого способы

- как ежедневно проверяемый на свою надежность и скорость работы с данными сотнями и миллионами пользователей во всем мире.


2. Я за максимально объектный подход, поэтому если СУБД может предоставить метод типа createNewOrganization(NewOrgName ...), то и надо его вызывать, а не разбираться в том вставляются ли при этом данные в таблицу пользователей, организаций, назначения роли пользователю с использованием роли по умолчанию, при этом используется линк к другой базе (если она стала распределенной), как оформляется начало и окончание этой распределенной транзакции и т.д. и т.п.

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

Какая альтернатива?
Элементарно, например, берем Hibernate, оборачиваем все в DAO и там инкапсулируем ту же функциональность, на самом деле получаем практически ту же процедуру, но работающую зачастую менее эффективно.

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

А вот чем:
- На самом деле у нас уже есть "класс", который отвечает за работу - это, грубо говоря, СУБД, ага такая вся из себя с необъектно ориентированными процедурами.
Я не вижу смысла дублировать его работу.

- Если мне придет в голову сменить версию сервера приложений, используемый язык или платформу, в случае, когда возможности СУБД используются максимально, это произойдет довольно спокойно, т.к. неизбежные глюки хотя и попьют крови, но с нашими драгоценными данными ничего страшного сделать не смогут (ну разве что, если просто туда вводить ложную информацию).

- Если, бЯда, мне таки придется сменить не приложение, а, наоборот, СУБД, то у JAVA (как пример) программиста голова болеть особо не будет он и понятия не имеет о том, что у меня теперь другое число таблиц, кардинально изменилась их структура, наименование, вида блокировок, методы контроля доступа ...
Максимум что "бедолаге" придется поправить так это синтаксис вызова метода.
Да и то, вот тут-то как раз DAO и облегчит нам задачу, только его обязанность будет не заново все update и select проверять и изобретать, а просто динамически менять синтаксис в зависимости от версии базы (это если мы решили, что должны теперь иметь возможность работать с несколькими разными СУБД).

А теперь представьте себе веселье в обратном случае, когда вдруг оказалось, что текущая версия Hibernate знает не все необходимые фичи новой базы или глючно с ними работает, или мы как-то не готовы становиться DBA еще и по новой СУБД, а увольнять нас нет смысла, т.к. мы JAVA хорошо знаем?

Ну и т.п.
...
Рейтинг: 0 / 0
29.01.2010, 14:22
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36439099
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
carperХотелось бы услышать мнение сообщества, а не навязывать свое, т.к. свое вызывает у меня некоторые неприятные подозрения. :)Тут недавно обсуждали такое: Хранимые процедуры против обычных SQL-запросов

carperДля затравки я попробую выступить от имени сторонника хранения бизнес-правил в основном в СУБД, для чего процитирую свое же сообщение с другого форума (только кусок, а то и так много букв):
Ну прям как я говорил :-)
...
Рейтинг: 0 / 0
29.01.2010, 15:58
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36439247
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
Нереально много букф. Из всего понял, что автора волнует проблема портируемости кода. Хотя эта проблема и связана с выбором узла для размещения "бизнес логики", но всё же не в ключе СУБД/Middleware/клиент, а в ключе поддержки конкретного языка и runtime окружения на конкретной платформе. Если Оракл поддерживает PL/SQL и Java на всех уровнях, то и проблема выбора не стоит так остро.

Если брать Middleware это наверное всё же J2EE и некоторый простор для выбора вендора.
Если брать СУБД, то стандартизован только SQL и то в силу технических особенностей перенос базы данных и SQL запросов не проходит гладко. Некотрые СУБД так же поддерживают Java но надо понимать, что runtime окружение сервера приложений и СУБД различаются.

Отчасти в деле переноса кода и данных помогают соответсвующие утилиты-мастера, так что наерное не стоит упираться в 100% портируемость кода, а больше внимания уделять архитектуре кода, чтобы в случае его переноса изменения были локализованы. Чтобы бизнес логика была изолирована от системных функций.
...
Рейтинг: 0 / 0
29.01.2010, 16:46
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36439340
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
alexeyvg,

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

Я же совсем не против серверов приложений, я никак не могу понять зачем они пытаются подменить СУБД?

Ну пускай сервер приложений парсит xml файлы, работает с почтой, получает данные с датчиков, биржевые тики раз в миллисекунду, балансирует нагрузку на другие сервера приложений и т.д. и т.п.

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

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

Но уж если есть бизнес-правило, согласно которому клерк больше 1000 баранов не может получать, то это надо проверять как можно ближе к телу.




Что касается статьи http://habrahabr.ru/blogs/refactoring/65432/, то, если принять за аксиому сразу два положения, явное и неявное:
- прямое утверждение "Базы данных разработаны для хранения, получения и обновления данных с максимально высокой эффективностью"
- подразумевающееся "и только для этого", то непонятно зачем он распинается дальше.
...
Рейтинг: 0 / 0
29.01.2010, 17:10
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36439351
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
mcureenab,
За много букв могу только повторно принести извинения. :(

Но боюсь, что без их прочтения вы не совсем поняли вопрос, возможно по моей вине, не знаю.
...
Рейтинг: 0 / 0
29.01.2010, 17:15
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36439434
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
carper,

привет =)

По мне хранения бизнес-логики это одна из особенностей системы. Причем ИМО имеет место процесс:

1. пишем standalone приложение. Оно работает с локальными файлами.
2. появляется несколько пользователей и файлы становятся разделяемым ресурсом. (файл-серверная архитектура). Логика только на клиентах.
3. файл-серверная архитектура показывает свои недостатки и их фиксают введением ОДНОЙ сущьности отвечающей за хранение - СУБД. Логика расползается между клиентом и СУБД.
4. для выполнения специфических задач - web-отображение, совместный доступ с другими компаниями - делается нечто также работающее в режиме сервера. Логика расползается на все три уровня (клиент, middleware, СУБД)
5. компания для минимизации своего труда старается собрать все на одном уровне. Клиент замыкается на middleware и становится отображением данных. Бизнес логика собирается либо на middleware, либо размазана между middleware и СУБД.

По мне оба подхода - вся логика на middleware ИЛИ вся логика на СУБД - ущербны по сути. middleware и СУБД решают разные задачи, далеко не всегда пересекающиеся.

Опять же ИМХО наилучшим решением было бы обобщенное программирование и СУБД и middleware. К примеру когда схема Oracle является доменной моделью приложения на J2EE. Слои Entity и DAO существуют именно в виде схемы данных Oracle.

У Sun не было своей СУБД и достаточных ресурсов... потому они подобное и не сделали. Возможно Oracle таки сможет это реализовать. Тогда и ХП и логика middleware будет писаться на одном языке и фактически приложение будет одновременно на СУБД и middleware. Далее только указывается МЕСТО работы логики - СУБД/AppServer/Client.

PS эх... мечты... мечты...
...
Рейтинг: 0 / 0
29.01.2010, 17:54
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36439475
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
VoDA,

"По мне оба подхода - вся логика на middleware ИЛИ вся логика на СУБД - ущербны по сути"

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

Как не попрошу их (или сам делаю), например, с использованием Hibernate изобразить какую-нибудь не совсем тривиальную, но и не сложную, вставку так получается, что у меня написать хранимку (при том, что я как раз больше по части JAVA), занимает времени раза в два меньше, смотрится все куда приятней и в тот же Hibernate вызов полученной хранимки вписывается без проблем.

Что касается попыток заставить СУБД делать не свои задачи, так тут же обратная картинка, правда в резко ухудшенном варианте, как-то базы уж очень плохо заточены не на свои задачи.


"К примеру когда схема Oracle является доменной моделью приложения на J2EE. Слои Entity и DAO существуют именно в виде схемы данных Oracle."

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

Может я неверно понял?
Как, например, в идеале должна лежать Entity и DAO в базе, чтобы это дало какие-то преимущества и как быть с различным отражением одних и тех же реляционных таблиц в сущности на разных языках?
Мы ведь не можем зацикливать данные на JAVA?
Как быть с Entity, если часть данных она получает из plain файлов или других баз, зачем ее пихать в одну базу?
...
Рейтинг: 0 / 0
29.01.2010, 18:14
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36439490
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
carperЯ же совсем не против серверов приложений, я никак не могу понять зачем они пытаются подменить СУБД?


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

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

Проверку БД можно выполнять на любом уровне. Чем ближе к БД, тем конечно меньше вероятность искажения данных. Но и до паранои доходить не следует.

Совать в схему БД все бизнес правила дело очень неблагодарное. Вопервых возможности СУБД тут могут быть недостаточны, во вторых БП вообще говоря меняются, и потолочная зарплата клерка в 2000м году уже сильно отличается от таковой в 2010м. Попытка применить новые БП к старым данным скорее всего провалится.

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

Наконец нет и не может быть рецепта правильной системы. В реальном мире мы сталкиваемся со множеством требований, ограничений и противоречий идём на компромисс. Ограничивая себя некой догмой, мы можем не найти приемлемого решения простой задачи. Разнообразие подходов связано не с тем они постепенно становятся лучше, а с тем, что для решения разных задач нужны разные подходы.
...
Рейтинг: 0 / 0
29.01.2010, 18:25
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36439751
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kachalov
Участник
Публикация данного топика в разделе "Проектирование БД" по видимому уже подразумевает позицию автора топика в пользу хранения логики в БД, однако попытаюсь вяло подискутировать:

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

carperЯ же совсем не против серверов приложений, я никак не могу понять зачем они пытаются подменить СУБД?
- если под термином СУБД опять имеется в виду Oracle, то очевидно что разработчики серверов приложений пытаются откусить его долю рынка (что из этого вышло, Вы знаете, и агрессивное поглощение Sun компанией Oracle думаю подтверждает мою мысль)

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

carper
Полностью от ошибок не защитит ничто, например, сервер приложений может сбойнуть, что-то не так распарсить в письме, и скажем, выставить зарплату клерку не 600 баранов, а 608 и СУБД этого не заметит.
- не понимаю что значит "сбойнуть"? ну а если СУБД "сбойнет"? Чем объектные транзакции хуже чем транзакции уровня СУБД?

carper
Но уж если есть бизнес-правило, согласно которому клерк больше 1000 баранов не может получать, то это надо проверять как можно ближе к телу.
- ключевое слово "бизнес правило". Что СУБД знает о бизнесе? :) Честно говоря это выглядит как рассуждения нуба от программирования. Один из первых тезисов при изучении программирования - константы не должны дублироваться, в противном случае при изменении одной константы и неизменности другой, аналогичной по смыслу константы, мы получим странно работающий код. Зачем делать проверку в СУБД (видимо с помощью ХП?) когда точно такая же проверка будет проводиться при обработке входных данных на уровне сервера приложений?

carper
получается, что у меня написать хранимку (при том, что я как раз больше по части JAVA), занимает времени раза в два меньше, смотрится все куда приятней и в тот же Hibernate вызов полученной хранимки вписывается без проблем.
- думаю Вы понимаете что "быстро написанное" это не синоним "масштабируемое", "удобное" и т. п.

carper
логично чтобы за их (данных) целостность и не противоречивость отвечала СУБД
...
- На самом деле у нас уже есть "класс", который отвечает за работу - это, грубо говоря, СУБД, ага такая вся из себя с необъектно ориентированными процедурами.
Я не вижу смысла дублировать его работу.
- термин "класс" в данном контексте непонятен, но в любом случае очевидно, что чем меньше мы "работаем" с данными, тем "целее" и "непротиворечивее" они будут :) В связи с чем вывод - СУБД как ответственная за целостность и непротиворечивость данных работать с ними не должна.



Что касается статьи http://habrahabr.ru/blogs/refactoring/65432/, то, если принять за аксиому сразу два положения, явное и неявное:
- прямое утверждение "Базы данных разработаны для хранения, получения и обновления данных с максимально высокой эффективностью"
- подразумевающееся "и только для этого", то непонятно зачем он распинается дальше.[/quot]
...
Рейтинг: 0 / 0
29.01.2010, 23:33
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36439846
Emix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Emix
Гость
Приложение прежде всего должно решать проблему заказчика.
Поэтому, считать, что данные важнее логики или логика важнее данных неправильно.
Одно без другого теряет смысл. И заменить не может.

Из выше написаного может появиться впечатление, что если что-то "сбойней",
то это обязательно сервер приложений.
Все может сбойнуть.
На личном опыте сбойнули с потерей данных Oracle, MS-SQL на нормальном железе.
СУБД Oracle устанавливал специалист с Oracle. Нету 100% гарантии нигде.
Можно только максимально уменьшать риски.

Hibernate уже достаточно зрелая технология. И предполагать, что вдруг все заглючит именно на СП, странно.

Даже если и будет желание поменять Hibernate на другой ORM - тоже можно.
Spring позволит это сделать без переписывания бизнес-логики.
Используем JPA и меняем конкретную ее реализацию: Toplink, Eclipselink, OpenJPA.


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

Java, C# более гибкие, чем PL/SQL, T-SQL.
Конечно, можно Java использовать и в СУБД. Но на практике это редко.
Том Кайт рекомендовал использовать Java только тогда, когда PL/SQL сам не может решить задачу.

Дальше развиваем проект на примере книжного магазина.
Представим, что у книжного магазина нужно логировать действия пользователя.
Причем, чтобы можно было динамически менять уровни детализации, или отключать вообще.
Через месяц заказчик хочет, чтобы обязательные поля менялись в зависимости от типа клиента.
PL/SQL - нужно вписывать много вложеных if-else if ...
В Java при правильной ОО архитектуре можно сделать так,
чтобы задача решилась вообще без изменения изначального кода (класса),
Можно использовать AOP, использовать подходящие шаблоны (типа Strategy, Proxy, Adapter ...)

А теперь представим, что у этого книжного магазина есть 1C.
И нужно, чтобы в одной транзакции была запись в две базы (БД магазина и 1С).
Hibernate и другие ORM могут решить эту задачу.

Еще вариант. Контора решила перейти на другую СУБД.
Да, и сегодня бывают такие ситуации. На практике случалось.
Хранимки переписывать, утилиты использовать, потом оттачивать?
Конфиг легче поменять.

В Java будет намного проще использовать готовые пакеты логики в других новых проектах,
либо использовать сторонние библиотеки в данном проекте, допустим, API для работы с Amazon.

Java программеров больше, чем PL/SQL, T-SQL...
Легче будет друг друга заменить (болезнь, отпуск, уволился ...).
Это важный организационный и экономический фактор.

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

Если возможно, то нужно стремиться, чтобы вся логика приложения была в одном месте,
а не по всему зоопарку технологий.
В Google даже сумели логику представления (JavaScript) перенести на Java :) - GWT

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

PS.
Рекомендую таки прочитать Implementing Referential Integrity and Shared Business Logic (особенно вторую часть)
Книга писалась еще в 2003 году
...
Рейтинг: 0 / 0
30.01.2010, 02:44
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36439865
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
carperМне кажется тут есть разумный компромисс, распределения ответственности - забота о добывании данных для вставки их в базу это не работа базы, ее дело обеспечить максимально прозрачное их хранение и непротиворечивость.
Непротиворечивость данных с точки зрения СУБД и непротиворечивость данных с точки зрения БЛ могут существенно отличаться. Далеко не все правила БЛ можно напрямую странслировать в правила СУБД. С другой стороны, БЛ "на выходе" дает некие алгоритмы манипулирования данными в СУБД, которые и нужно держать непосредственно в СУБД. Поскольку современные СУБД позволяют расширять свой функционал - они также могут представлять не только уровень данных, но и уровень бизнес-логики. Чем проще эта логика - тем ближе ее можно разместить к данным. Выбор этой близости - как правило профессионализм архитектора\разработчика, а не какая-то объективная оценка. Иначе не было бы войн типа "Хранимки vs Запросы", "Хранимки vs СерверПриложений", "СерверПриложений vs ТолстыйКлиент" и т.д.
carperПолностью от ошибок не защитит ничто, например, сервер приложений может сбойнуть, что-то не так распарсить в письме, и скажем, выставить зарплату клерку не 600 баранов, а 608 и СУБД этого не заметит. Никакие хранимые процедуры тут не помогут, даже наоборот, централизованная ошибка еще хуже. Но уж если есть бизнес-правило, согласно которому клерк больше 1000 баранов не может получать, то это надо проверять как можно ближе к телу.
Технический сбой какого-то модуля при многозвенной обработке можно решить, например, многозвенными же транзакциями. Конкретная реализация этих транзакций - опять таки профессионализм архитектора\разработчика. Полностью, конечно, не защитит. Но даст очень высокую степень надежности. И, возможно, инструментарий "быстрого реагирования" на подобные сбои.

С дургой стороны, возьмем Ваш пример. Где, по Вашему, должно находиться это "ближе к телу" в этом конкретном случае? Как определить, что начисленные 608 баранов - "сбой парсера почты"? На каком уровне должно быть описано бизнес-правило "клерк получает не более 1000 баранов"?
Ответы на подобные вопросы и будут определять архитектуру системы. Кто-то сможет и "парсер почты" затолкать в СУБД, и все правила описать в виде хранимок. Кто-то все сделает на клиенте, используя БД как "хранилище dbf". Кто-то сделает "сервис разбора почты"+"сервис начисления баранов" на сервере приложений и "процедуру движения начисления" в БД. И все эти варианты будут работать. В конкретных условиях конкретного пользователя. Перенести же выбранную (и вроде как даже проверенную) схему на другие условия может оказаться или вообще невозможно, или проблематично, или потребует пусть и минимумальных, но доработок. Но каждая такая система может найти своих приверженцев и в технических, и в бизнес кругах. И в каждом таком круге найдутся те, кто будет "с пеной у рта" доказывать идеальность любимой системы. Ничего страшного в этом нет - "все мы люди, все мы человеки". :)

PS. А серебрянные пули таки бывают. ;) Но обычно они эффективны против очень узкого круга животных :)

PPS. В примерах использовались "абстрактные системы". Все совпадения с реальными системами - абсолютно случайны. :)
...
Рейтинг: 0 / 0
30.01.2010, 04:17
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36439926
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
EmixСодержание бизнес-логики на сервере приложений дает большую гибкость
и уменьшает затраты на развитие проекта, поддержку.
При проектировании легче оперировать понятиями объектов и их ассоциациями,
а не таблицами и хранимыми процедурами.

есть какие-нибудь мысли по обоснованию или воспринимать как "личное мнение не основанное на сравнении и анализе"?

EmixJava, C# более гибкие, чем PL/SQL, T-SQL.
есть одно наблюдение... чем гибче язык требуется для описания бизнес-логики, тем более коряво она(бизнес-логика) спроектирована , без гибкости языка просто не обойтись.

Emixразвиваем проект на примере книжного магазина.
Представим, что у книжного магазина нужно логировать действия пользователя.
Причем, чтобы можно было динамически менять уровни детализации, или отключать вообще.
Через месяц заказчик хочет, чтобы обязательные поля менялись в зависимости от типа клиента.
PL/SQL - нужно вписывать много вложеных if-else if ...

в принципе, подтверждение наблюдения чуть выше.

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

достаточно проектировать логику так, чтобы если и что-то выпадало, то по конкретной причине в одном месте, а не покрывать систему юнит-тестами, в качестве заглушек для поиска пробелов в архитектуре.
...
Рейтинг: 0 / 0
30.01.2010, 10:53
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36439981
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kachalov
Участник
iscrafm, во всех процитированных Вами тезисах Emix поддержу Emix

P.S. iscrafm , Ваши тезисы сводятся к упорном повторению "нет" на все тезисы оппонента и не содержат в себе каких-либо аргументов, подтверждающих обоснованность Вашей позиции

P.P.S. В очередной раз понимаю, что заниматься программированием должны программисты, а не администраторы баз данных, системные администраторы, бухгалтера и т. п.
...
Рейтинг: 0 / 0
30.01.2010, 12:33
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440001
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
EmixПриложение прежде всего должно решать проблему заказчика.
Поэтому, считать, что данные важнее логики или логика важнее данных неправильно.
Одно без другого теряет смысл. И заменить не может.
+1000.
EmixИз выше написаного может появиться впечатление, что если что-то "сбойней",
то это обязательно сервер приложений.
Все может сбойнуть.
На личном опыте сбойнули с потерей данных Oracle, MS-SQL на нормальном железе.
СУБД Oracle устанавливал специалист с Oracle. Нету 100% гарантии нигде.
Можно только максимально уменьшать риски.
Hibernate уже достаточно зрелая технология. И предполагать, что вдруг все заглючит именно на СП, странно.
Не страннее, чем вышеописанный Вами сбойнувшие "Oracle, MS-SQL на нормальном железе". Вы же не думаете, что Hibernate более зрелая технология, чем используемая в Oracle и MSSQL?
EmixДаже если и будет желание поменять Hibernate на другой ORM - тоже можно.
Spring позволит это сделать без переписывания бизнес-логики.
Используем JPA и меняем конкретную ее реализацию: Toplink, Eclipselink, OpenJPA.
Но ведь это опять вопрос на откуп конкретному архитектора\разработчика - Вы считаете, что ORM - обязательный компонент для связи бизнес-логики с базой данных, я же, например, считаю что ORM в ныненшнем виде совершенно необязательный компонент системы. Кто прав? ;)Объективного критерия-то нет...
EmixСодержание бизнес-логики на сервере приложений дает большую гибкость
и уменьшает затраты на развитие проекта, поддержку.
При проектировании легче оперировать понятиями объектов и их ассоциациями,
а не таблицами и хранимыми процедурами.
Опять таки кому как. Кому-то легче оперировать, например, сущностями и связями, чем объектами.
EmixJava, C# более гибкие, чем PL/SQL, T-SQL.
Конечно, можно Java использовать и в СУБД. Но на практике это редко.
Том Кайт рекомендовал использовать Java только тогда, когда PL/SQL сам не может решить задачу.
В общем и целом - описание бизнес-логики к языку программирования имеет слабое отношение. Тут соглашусь с iscrafm, чем более гибкий язык требуется для описания безнес-логики, тем хуже она спроектирована.
EmixДальше развиваем проект на примере книжного магазина.
Представим, что у книжного магазина нужно логировать действия пользователя...
На мой вкус, это некорректный пример. Ибо если аудит не включен в саму архитектуру изначально - без переделеки архитектуры это будут "примочки" и "извраты" разной степени сложности.
EmixЕще вариант. Контора решила перейти на другую СУБД.
Да, и сегодня бывают такие ситуации. На практике случалось.
Хранимки переписывать, утилиты использовать, потом оттачивать?
Конфиг легче поменять.
Такой пример меня вообще ставит в ступор. Контора решила перейти на другую СУБД с бухты-барахты? Или потому что система, разработанная под существующую СУБД уперлась в ее ограничения, которые разработчик системы не учел при проектировании? Или вовремя не подумали о том, что выбранная СУБД требует лицензионных отчислений? Или почему принято решение сменить СУБД без замены системы, её использующей? Лично я, хотя и не считаю, что приложения поддерживающие множество СУБД не имеют права на жизнь. Но также не считаю правильным использовать мощные современные СУБД только как "хранилище dbf". Но это опять таки - мнение конкретного архитектора\разработчика, а не какая-то объективная реальность :)
EmixВ Java будет намного проще использовать готовые пакеты логики в других новых проектах... либо использовать сторонние библиотеки в данном проекте...
В .NET будет намного проще использовать готовые пакеты логики в других новых проектах...
В Delphi будет намного проще использовать готовые пакеты логики в других новых проектах...
И будете смеяться, но
В Oracle будет намного проще использовать готовые пакеты логики в других новых проектах...
В MSSQL будет намного проще использовать готовые пакеты логики в других новых проектах...
Все зависит от конкртеного разработчика...
EmixJava программеров больше, чем PL/SQL, T-SQL
Обосновать можете?
EmixЮнит тесты. Когда вся бизнес-логика в одном месте,
то легче "покрыть" приложение тестами, что повысит надежность системы в целом.
Юнит-тесты хороши на очень начальной стадии разработки, когда эти самые юниты еще не "устаканены" и\или базовые модули системы подгоняются по мере отрисовки каркаса архитектуры. Или это высказывание говорит о том, что изменение бизнес-логики потребует существенной переделки кода системы. Можете обосновать, чем лучше такой подход выделением исполнения бизнес-логики в отдельный слой, который к архитектуре системы имеет весьма слабое отношение?
...
Рейтинг: 0 / 0
30.01.2010, 13:04
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440029
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
KachalovP.S. iscrafm , Ваши тезисы сводятся к упорном повторению "нет" на все тезисы оппонента и не содержат в себе каких-либо аргументов, подтверждающих обоснованность Вашей позиции

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

есть какие-нибудь мысли по обоснованию или воспринимать как "личное мнение не основанное на сравнении и анализе"?
...
Рейтинг: 0 / 0
30.01.2010, 13:32
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440030
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
Я считаю, что последним кто проверяет и действительно хранит все в целостном виде - база данных - все время в своих проектах использую контроль бизнес-правил на сервере БД, чтобы при их изменении не ковырять N-слоев и не иметь геморрой в случае если гдето обшибся в N-м слое
...
Рейтинг: 0 / 0
30.01.2010, 13:32
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440041
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Kachalovзаниматься программированием должны программисты, а не администраторы баз данных, системные администраторы, бухгалтера и т. п.
неоспоримый тезис. Странно было бы услышать, что заниматься программированием должен бухгалтер, сисадмин или DBA. Только речь идет об архитектуре.
...
Рейтинг: 0 / 0
30.01.2010, 13:42
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440076
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kachalov
Участник
iscrafmесли Вы не обратили внимания, то речь идет об обратном.

iscrafmесть какие-нибудь мысли по обоснованию или воспринимать как "личное мнение не основанное на сравнении и анализе"?


- если я правильно понял, Вам можно спрашивать у оппонентов чем они обоснуют свое мнение, а Вас о том же спрашивать нельзя?

iscrafmСтранно было бы услышать, что заниматься программированием должен бухгалтер, сисадмин или DBA. Только речь идет об архитектуре.
- точно, архитектурой должен заниматься архитектор, а не DBA, сисадмин или бухгалтер :)
...
Рейтинг: 0 / 0
30.01.2010, 14:13
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440102
Джамшид Ровшан
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Джамшид Ровшан
Гость
sp,

ну тады твоя БД запутана в сетях триггеров :(
...
Рейтинг: 0 / 0
30.01.2010, 14:48
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440114
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Kachalov- если я правильно понял, Вам можно спрашивать у оппонентов чем они обоснуют свое мнение, а Вас о том же спрашивать нельзя?

почему же, можно конечно. Спрашивайте, после того, как выскажу мнение. Нить беседы умышленно запутываете?
...
Рейтинг: 0 / 0
30.01.2010, 15:02
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440116
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Kachalovархитектурой должен заниматься архитектор, а не DBA, сисадмин или бухгалтер
какие еще прописные истины выдадите в качестве откровений?
...
Рейтинг: 0 / 0
30.01.2010, 15:05
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440140
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kachalov
Участник
iscrafmкакие еще прописные истины выдадите в качестве откровений?
- рад, что Вы понимаете что речь идет именно о "прописных истинах", в связи с чем откланяюсь, я хоть по профессии и не архитектор, но соответствующую литературу вынужденно штудировал. И как не странно ни в одном руководстве не встретил совета описывать бизнес логику в виде хранимых процедур. Да и самому мне, неандертальский стиль программирования, демонстрируемый с помощью ХП, как-то противен.

iscrafmпочему же, можно конечно. Спрашивайте, после того, как выскажу мнение. Нить беседы умышленно запутываете?
- познавательная ценность данного поста 0%, но в плане померяться писюнами, он не лишен смысла.
...
Рейтинг: 0 / 0
30.01.2010, 15:41
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440175
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Kachalovни в одном руководстве не встретил совета описывать бизнес логику в виде хранимых процедур. Да и самому мне, неандертальский стиль программирования, демонстрируемый с помощью ХП, как-то противен.

почему в виде ХП обязательно?
Насчет неандартальского стиля....
требуется у, допустим, контрагентов, чьи реквизиты удовлетворяют определенному условию, заменить значение поля А1 с 25 на 30. Приведите плз пример как делают в просвещенном обществе такую операцию.
Мой вариант ниже
Код: plaintext
update customers set A1 =  30  where <условие>
посмотрим на познавательную ценность.

p.s. сдержанность это не порок.
...
Рейтинг: 0 / 0
30.01.2010, 16:08
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440179
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Kachaloviscrafmпочему же, можно конечно. Спрашивайте, после того, как выскажу мнение. Нить беседы умышленно запутываете?
- познавательная ценность данного поста 0%, но в плане померяться писюнами, он не лишен смысла.
так Вы что-то спросить хотели или...? Можно чуть логичней выражать свои мысли, пожалуйста. В теме про логику.
...
Рейтинг: 0 / 0
30.01.2010, 16:10
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440187
Emix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Emix
Гость
авторПри проектировании легче оперировать понятиями объектов и их ассоциациями,
а не таблицами и хранимыми процедурами.
(обоснование по поводу гибкости уже было описано +читать дальше)
Обосноване.
Есть сущности: Заказчик, Корпоративный Заказчик, Средний Заказчик.
ОО:
CorporativeCustomer --|> Customer <|-- MiddleCustomer
CorporativeCustomer и MiddleCustomer наследуются от Customer.

Послать счет заказчику:
Код: plaintext
1.
2.
Customer someCostomer = ...
Bill bill = prepareBill(someCostomer);
someCustomer.sendBill(bill);

Через пол года добавляем нового типа клиента SmallCustomer...
Теперь опишите это в таблицах и хранимых процедурах
и сравните какими понятиями легче оперировать и что будет более гибко.
Рекомендую почитать книгу Крега Лармана
(продолжать по этому поводу не буду)

авторчем гибче язык требуется для описания бизнес-логики, тем более коряво она(бизнес-логика) спроектирована
Если у вас именно так и получается, то используйте негибкие языки.
У меня - наоборот. На PL/SQL когда-то писал почти два года. Меня Java больше устраивает для моих целей.

авторВы же не думаете, что Hibernate более зрелая технология, чем используемая в Oracle и MSSQL?
зрелая на достаточном уровне, чтобы применять в production-приложениях.
Oracle тоже почему-то создал свой ORM - Toplink. PL/SQL тоже зрелый, а может и "перезрелый" :) .

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

автор...В Oracle будет намного проще использовать готовые пакеты логики в других новых проектах...
В MSSQL будет намного проще использовать готовые пакеты логики в других новых проектах...
Но готовых библиотек на Java намнооого больше, чем у PL/SQL и T-SQL вместе взятых.

По поводу количества программистов. Я думал, что это будет очевидно.
Ладно, смотрим тут , смотрим тенденции там
Мало? тут еще много доказательства .

авторЮнит-тесты хороши на очень начальной стадии разработки...
Тесты нужны и обязательны на всех стадиях и это влияет на выбор архитектуры.

По поводу "выпаданий в одном месте" и "...чтобы при их изменении не ковырять N-слоев...".
В том то и дело! В данном примере с книжным магазином желательно, чтобы вся логика была на СП,
а не уровне представления или базы данных.

Пример.
Задача: добавилось два поля в сущность Customer.
Нужно чтобы система контролировала: минимум 1 из них обязательно должно быть заполенным.
И в зависимости от выбора перенаправлять на одну из следующих страниц.
Если контроль не проходит, пользователь должен увидеть уведомление ("ошибку") на его родном языке.

Если эту логику решать с помощью хранимок, тригеров и ограничений,
то код логики будет дублироваться и на других слоях,
поскольку СУБД вообще не должна знать о каких-то там страницах, формах...
Берем старую модель и поля будут проверяться:
- в СУБД (PL/SQL, T-SQL). Не проходит требование - ошибка (с кодом ошибки).
- в контроллере (Java, C#, PHP, Python...) Не проходит требование - вылавливаем код ошибки и выводим сообщение на нужном языке.
- на клиенте (JavaScript, Swing...) ловим ошибку либо от контролера, либо (... отдельный вопрос)

Конечно, вы можете придумать что-то лучше.
Но давайте рассмотрим, если все это на сервере приложений.
СП проверяет значения.
Код: plaintext
if (field1.isBlank() && field2.isBlank) throw new ValidationException(message.toLocale()); /*что-то типа того*/
и передает это уровню презентации.

СП находится между уровнем данных и уровнем презентации,
поэтому ему легче конролировать логику приложения в целом
и без дублирования или разнесения логики по другим слоям.
...
Рейтинг: 0 / 0
30.01.2010, 16:18
| Ответить | Цитировать | Написать  
25 сообщений из 318, страница 1 из 13
  1  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Где должна лежать бизнес-логика в мнгоуровневом приложении
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=36439340&tid=1542824]:
 0ms
get settings:
 6ms
get forum list:
 11ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 141ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 69ms
get tp. blocked users:
 1ms
others: 206ms
total:  450ms
созд. / загр.: 450ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]