ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Где должна лежать бизнес-логика в мнгоуровневом приложении
318 сообщений из 318, показаны все 13 страниц
  все  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #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
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440229
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
EmixавторПри проектировании легче оперировать понятиями объектов и их ассоциациями,
а не таблицами и хранимыми процедурами.
(обоснование по поводу гибкости уже было описано +читать дальше)
Обосноване.
Есть сущности: Заказчик, Корпоративный Заказчик, Средний Заказчик.
ОО:
CorporativeCustomer --|> Customer <|-- MiddleCustomer
CorporativeCustomer и MiddleCustomer наследуются от Customer.

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

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

уточните плз, чем отличаются сущности Заказчик, Корпоративный заказчик, Средний, Маленький и т.п. в принципе и чем у них отличается процедура отправки счета, в частности.
С ХП это конечно не в тему, СУБД счета не отправляет.


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

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

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

естественно не должна. Она и не знает. Банальная валидация ввода.
...
Рейтинг: 0 / 0
30.01.2010, 17:01
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440236
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kachalov
Участник
iscrafm
Насчет неандартальского стиля....
требуется у, допустим, контрагентов, чьи реквизиты удовлетворяют определенному условию, заменить значение поля А1 с 25 на 30. Приведите плз пример как делают в просвещенном обществе такую операцию.
- честно говоря, уже само название поля "A1" выдает в собеседнике "неандертальского программиста"

iscrafmтак Вы что-то спросить хотели или...? Можно чуть логичней выражать свои мысли, пожалуйста. В теме про логику.
- познавательная ценность данного поста 0%
...
Рейтинг: 0 / 0
30.01.2010, 17:10
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440301
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
Чтобы немного разредить обстановку :)
"Гармонией называлась дочь Афродиты и Ареса — богини любви и бога войны. Гармония… возникает из противоположностей. Ибо гармония есть соединение разнообразной смеси и согласие разнообразного."

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

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

Ok, про достоинства ясно. А какие недостатки имеет решение хранения логики на сервере приложений?

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

Чем объектные транзакции хуже чем транзакции уровня СУБД?]
Вы полагаете, что перенесение кучи DML на уровень сервера приложений делает транзакцию объектной, а выполнение аналогичного (разве что более удобного) кода в хранимой процедуре и вызов этой процедуры тем же сервером приложений сразу превращает эту транзакцию в нечто иное?

Это не риторический вопрос, я бы действительно хотел понять почему?

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

Нет?

СУБД как ответственная за целостность и непротиворечивость данных работать с ними не должна.
П'ппереведите ! :)


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

Извините, но кто-то где-то призывал отказаться от ORM и их помощи?

Ради бога, вызывайте ХР на 1С (к вопросу о птичках, структура таблиц в 1C закрытая и разработчики, мягко говоря, не приветствуют внешние элементарные DML операции, так что пример с 1С неудачен) и на том же Oracle с помощью все того же Hibernate.

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

Вот знать, что отдать 1С, а что Oracle и должен сервер приложений, это его работа.

и уменьшает затраты на развитие проекта, поддержку.
Т.е. написать ХР и код ее использующий на сервере приложений, трудней и требует большей поддержки, чем написание ее же (ХР) варианта на сервере приложений?
Можно увидеть доводы?


авторJava программеров больше, чем PL/SQL
Во-первых, не уверен, но это и не важно, чего это мы на JAVA съехали, сервера приложений что только на JAVA пишут? :)

Если используем СУБД только как хранилище, максимально уходя от специфики и наплевав на производительность, то довод принимается.

Если же нет, то любой из наших JAVA программистов просто превратится в DBA поневоле, с соответствующей дефицитностью и окладом.

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

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

Мне кажется, что разнесение БЛ по разным местам тут не так уж плохо, особенно, если к одной СУБД имеют доступ более одного приложения, да еще написанные разными разработчиками.

Да, пока не забыл, спасибо, книгу обязательно почитаю.


Егоров Александр
Далеко не все правила БЛ можно напрямую странслировать в правила СУБД. С другой стороны, БЛ "на выходе" дает некие алгоритмы манипулирования данными в СУБД, которые и нужно держать непосредственно в СУБД

Согласен, но вот в этой же теме многие против такого подхода.
В чем же причина?

Как определить, что начисленные 608 баранов - "сбой парсера почты"?
А никак, только бухгалтерскими методами двойных проводок, при сдаче баланса будет небольшой скандальчик, только и всего. :)
...
Рейтинг: 0 / 0
30.01.2010, 18:32
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440337
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Kachaloviscrafm
Насчет неандартальского стиля....
требуется у, допустим, контрагентов, чьи реквизиты удовлетворяют определенному условию, заменить значение поля А1 с 25 на 30. Приведите плз пример как делают в просвещенном обществе такую операцию.
- честно говоря, уже само название поля "A1" выдает в собеседнике "неандертальского программиста"

ну назовите B1, Discount как угодно. Зачем клоунаду устраивать.
...
Рейтинг: 0 / 0
30.01.2010, 19:09
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440338
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
Emixавторчем гибче язык требуется для описания бизнес-логики, тем более коряво она(бизнес-логика) спроектирована
Если у вас именно так и получается, то используйте негибкие языки.
У меня - наоборот. На PL/SQL когда-то писал почти два года. Меня Java больше устраивает для моих целей.
Очень объективному аргумент "у меня..." всегда найдется не менее объективный аргумент "а у меня..." Свои цели я достигаю вообще не используя Java. Что я делаю не так? :)

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

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

В общем-то дальше отвечать тоже не буду. Ваша позиция мне ясна - "все нужно делать на СП, используя исключительно Java". "Любое добавление сущесности требует наследования\создания нового класса и перекомпиляции проекта с прогоном всех юнит-тестов". Переубедить Вас я вряд ли сумею, поэтому считаю дальнейший диалог бесцельным и провоцирующим очередной холивар страниц на 30-ть... :) Извините, если чем-то обидел.
...
Рейтинг: 0 / 0
30.01.2010, 19:10
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440341
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kachalov
Участник
carperП'ппереведите ! :)
- тезисы выдранные из контекста очень сложно объяснять, так как они теряют часть заложенного в них смысла. Думаю, что мелко нашинковав любой пост можно добиться что его смысл полностью поменяется :)
...
Рейтинг: 0 / 0
30.01.2010, 19:12
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440427
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
carperДалеко не все правила БЛ можно напрямую странслировать в правила СУБД. С другой стороны, БЛ "на выходе" дает некие алгоритмы манипулирования данными в СУБД, которые и нужно держать непосредственно в СУБД
Согласен, но вот в этой же теме многие против такого подхода.
В чем же причина?
На мой взгляд, главной причиной является желание отвязаться от кокретной СУБД. Разработка же специальных "драйверов СУБД" для оптимальной работы приложения с конкретной СУБД - весьма непростая задача. Особенно при отсутствии декларативного подхода к описанию этих самых алгоритмов манипулирования. Лично мне непонятна такая погоня за универсальностью, но и критиковать "с пеной у рта" такие системы я не буду.
Для отражения операции "резервирование товара по заказу" кому-то проще перегнать кучу данных из БД на СП, обработать их, и залить обратно, используя только свой любимый язык\библиотеку "и ни капли SQL!", кому-то проще написать хранимку, используя свой любимый диалект SQL "и ни строчки на клиенте не трогать!".

Не имея какого-то общепринятого стандарта описания бизнес-логики трудно даже сравнивать различные подходы к отражению это логики в конкретных системах. Ибо само понятие "бизнес-логика" каждый волен трактовать по-своему. У кого-то "запрет ввода пустого значения" - уже бизнес логика. У кого-то "обработка проведения" не является бизнес-логикой.
Как позицировать схему, в которой "запрет ввода пустого значения" отражен как ограничение not null в БД, которое передается клиенту в параметрах этого поля, а клиент сам включает у себя соответствующую валидацию? :) Или когда конструктор формы, увидев галку "непустое поле", передал в СУБД alter table add constraint ... а на СП - соответствующе поправленный XALM? :)
carperКак определить, что начисленные 608 баранов - "сбой парсера почты"?
А никак, только бухгалтерскими методами двойных проводок, при сдаче баланса будет небольшой скандальчик, только и всего. :)Ну... Это же был Ваш парсер - Вам его и чинить. :)
...
Рейтинг: 0 / 0
30.01.2010, 20:46
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440804
asdfghjkl;
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
asdfghjkl;
Гость
iscrafm
Мой вариант ниже
Код: plaintext
update customers set A1 =  30  where <условие>
посмотрим на познавательную ценность.

p.s. сдержанность это не порок.
Плохой вариант - а вдруг на поле есть зависимости, успешную часть надо закоммитить, по прочим маты озвучить.... Плохой вариант.
...
Рейтинг: 0 / 0
31.01.2010, 13:43
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440807
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
asdfghjkl;iscrafm
Мой вариант ниже
Код: plaintext
update customers set A1 =  30  where <условие>
посмотрим на познавательную ценность.

p.s. сдержанность это не порок.
Плохой вариант - а вдруг на поле есть зависимости, успешную часть надо закоммитить, по прочим маты озвучить.... Плохой вариант.
допустим, нет зависмостей. Вопрос состоит не в обработке зависимостей, а в способе реализации простейшей операции.
...
Рейтинг: 0 / 0
31.01.2010, 13:51
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440824
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
asdfghjkl;, отвлекся...
смысл был в том, чтобы посмотреть на объектную реализацию данной операции, о которой говорилось что она проще, доступней и легче в сопровождении.
Понятно, что можно банально, к примеру:

Код: plaintext
1.
2.
3.
4.
5.
6.
Session session = HibernateUtil.beginTransaction();
String sqltext = "update customers 
                set A1 = 30 
                  where <...>)";
Query query = session.createQuery(sqltext);
 int  rCount = query.executeUpdate();
HibernateUtil.commitTransaction();
но интересует вид именно "объектного решения"
...
Рейтинг: 0 / 0
31.01.2010, 14:15
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440866
Джамшид Ровшан
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Джамшид Ровшан
Гость
iscrafmasdfghjkl;, отвлекся...
смысл был в том, чтобы посмотреть на объектную реализацию данной операции, о которой говорилось что она проще, доступней и легче в сопровождении.
Понятно, что можно банально, к примеру:

Код: plaintext
1.
2.
3.
4.
5.
6.
Session session = HibernateUtil.beginTransaction();
String sqltext = "update customers 
                set A1 = 30 
                  where <...>)";
Query query = session.createQuery(sqltext);
 int  rCount = query.executeUpdate();
HibernateUtil.commitTransaction();
но интересует вид именно "объектного решения"

Customers.Where(t => t.A1==30).Set(t => t.A1=30).Save();
...
Рейтинг: 0 / 0
31.01.2010, 15:09
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440868
Не Хибернейт
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Не Хибернейт
Гость
iscrafmasdfghjkl;, отвлекся...
смысл был в том, чтобы посмотреть на объектную реализацию данной операции, о которой говорилось что она проще, доступней и легче в сопровождении.
Понятно, что можно банально, к примеру:

Код: plaintext
1.
2.
3.
4.
5.
6.
Session session = HibernateUtil.beginTransaction();
String sqltext = "update customers 
                set A1 = 30 
                  where <...>)";
Query query = session.createQuery(sqltext);
 int  rCount = query.executeUpdate();
HibernateUtil.commitTransaction();
но интересует вид именно "объектного решения"

Hibernate, по большому счету, - тривиальный DAL, который имеет весьма отдаленное отношение к бизнес-объектам. Объектное решение - Customers.Save() (сохраняем изменения во всем графе объекта). При изменениях в структуре БД не нужно менять клиентскую часть.
...
Рейтинг: 0 / 0
31.01.2010, 15:11
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440894
belugin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
belugin
Участник
или так
...
Рейтинг: 0 / 0
31.01.2010, 15:43
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36440909
asdfghjkl;
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
asdfghjkl;
Гость
iscrafmasdfghjkl;, отвлекся...
смысл был в том, чтобы посмотреть на объектную реализацию данной операции, о которой говорилось что она проще, доступней и легче в сопровождении.
Понятно, что можно банально, к примеру:

Код: plaintext
1.
2.
3.
4.
5.
6.
Session session = HibernateUtil.beginTransaction();
String sqltext = "update customers 
                set A1 = 30 
                  where <...>)";
Query query = session.createQuery(sqltext);
 int  rCount = query.executeUpdate();
HibernateUtil.commitTransaction();
но интересует вид именно "объектного решения"
Дак вот (ИМХО, конечно), именно объектный подход к решению в такой ситуации не выглядит как одна транзакция (в том виде, что этот термин сейчас обычно означает). Нотацию упрощенно можно представить себе как "Объект=Клиент,Операция=Обновить,Реквизит1=А1/Значение...,Дополнительно=УсловиеОтбора", тогда имеет хотя бы не конкретную функцию(черный ящик) на каждый чих, а некий один метод. И тут уже будет попроще его сопровождать, как бы технически он ни был сделан, т.к. техника уже вторична. А передать результаты метода "наружу" - любой вариант сможет )))
...
Рейтинг: 0 / 0
31.01.2010, 16:24
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441186
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
Егоров АлександрВ общем и целом - описание бизнес-логики к языку программирования имеет слабое отношение. Тут соглашусь с iscrafm, чем более гибкий язык требуется для описания безнес-логики, тем хуже она спроектирована.Бизнес-логика далеко не всегда проектируется... бывает что она сложилась исторически и именно ее нужно реализовать. Заказчик платит именно за это.

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

Егоров АлександрТакой пример меня вообще ставит в ступор. Контора решила перейти на другую СУБД с бухты-барахты? Или потому что система, разработанная под существующую СУБД уперлась в ее ограничения, которые разработчик системы не учел при проектировании? Или вовремя не подумали о том, что выбранная СУБД требует лицензионных отчислений? Или почему принято решение сменить СУБД без замены системы, её использующей? Лично я, хотя и не считаю, что приложения поддерживающие множество СУБД не имеют права на жизнь. Но также не считаю правильным использовать мощные современные СУБД только как "хранилище dbf". Но это опять таки - мнение конкретного архитектора\разработчика, а не какая-то объективная реальность :)Вот тут проявляется основная разница между DBA и разработчиками "серверного лагеря". Вы сидите в компании и у вас уже есть СУБД. Появление другой СУБД это явление очень редкое ибо требует много ЗАТРАТ на изменение.

Мы разрабатываем софт. У нас появление требования к продукту по поддержке еще одной СУБД - штатный запрос чтобы получить еще одного клиента и ЗАРАБОТАТЬ.

Мы не можем позволить себе обязывать клиента работающего на MS SQL ставить Oracle только для нашей системы. Мы подстраиваемся под запросы и можем перевести приложение на иную СУБД.

Егоров АлександрEmixJava программеров больше, чем PL/SQL, T-SQL
Обосновать можете? смотрим на процент java и PL/SQL тынц

Егоров АлександрEmixЮнит тесты. Когда вся бизнес-логика в одном месте,
то легче "покрыть" приложение тестами, что повысит надежность системы в целом.
Юнит-тесты хороши на очень начальной стадии разработки, когда эти самые юниты еще не "устаканены" и\или базовые модули системы подгоняются по мере отрисовки каркаса архитектуры. Или это высказывание говорит о том, что изменение бизнес-логики потребует существенной переделки кода системы. Можете обосновать, чем лучше такой подход выделением исполнения бизнес-логики в отдельный слой, который к архитектуре системы имеет весьма слабое отношение?Как раз на начальной стадии пока система не выведена в продакшен - на юнит-тесты можно забить. Они замедляют процесс разработки.

Изменение БЛ может потребовать любого изменения кода системы. До переписывания значительной его части. Процесс разработки должен выдерживать любое изменение кода без вывода системы из рабоче способного режима.

Так вынос БЛ в отдельный слой (на апп-сервер) и есть архитектурное решение.
...
Рейтинг: 0 / 0
31.01.2010, 22:03
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441189
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
spЯ считаю, что последним кто проверяет и действительно хранит все в целостном виде - база данных - все время в своих проектах использую контроль бизнес-правил на сервере БД, чтобы при их изменении не ковырять N-слоев и не иметь геморрой в случае если гдето обшибся в N-м слоек сожалению далеко не всегда СУБД знает что есть целостный вид данных. Конечно можно сделать проверку целостности типа "если товар имеет стоимость до 100 рублей (одна таблица) и введен в продажу до 31 декабря 2009 (другая таблица) и это разрешено менеджером (третья таблица), то разрешить продажу со скидкой до 5%".

Слишком быстро триггера станут похожи на лапшу...
...
Рейтинг: 0 / 0
31.01.2010, 22:06
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441195
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
iscrafmуточните плз, чем отличаются сущности Заказчик, Корпоративный заказчик, Средний, Маленький и т.п. в принципе и чем у них отличается процедура отправки счета, в частности.
С ХП это конечно не в тему, СУБД счета не отправляет.если вы хотите перенести БЛ на СУБД, то СУБД обязана отправлять счета. отправка счета это БЛ.

iscrafmпопытался найти связь аудита действий пользователей с бизнес-логикой, сходу не получилось. Давайте более бизнес-логичные примеры обсуждать.эм... а почему аудит у вас не БЛ? Бизнес-логика это логика системы требуемая для работы компании. Т.е. по сути БЛ это ВСЕ что хочет получить заказчик и за что он платит.

iscrafmестественно не должна. Она и не знает. Банальная валидация ввода.Валидация ввода это тоже БЛ. И кто же должен ее реализовать? А главное ГДЕ?
...
Рейтинг: 0 / 0
31.01.2010, 22:16
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441206
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
Егоров АлександрВаша позиция мне ясна - "все нужно делать на СП, используя исключительно Java". "Любое добавление сущесности требует наследования\создания нового класса и перекомпиляции проекта с прогоном всех юнит-тестов". Переубедить Вас я вряд ли сумею, поэтому считаю дальнейший диалог бесцельным и провоцирующим очередной холивар страниц на 30-ть... :) Извините, если чем-то обидел.я отвечу на сей пост, хотя он и не мне предназначен.

По мне в любой системе нужно ориентироваться на стоимость разработки и поддержки. При использовании java & app-server разработка обходится дешевле, чем на PL/SQL. Хотя наверняка найдутся задачи которые выгоднее решать на PL/SQL или вообще без СУБД.

И да. мое принципиальное мнение что любое изменение кода системы должно быть подтверждено прогоном юнитов. Мало того, я знаю что финансовые системы кроме просто прогона юнитов еще и юниты поверх кластеров гоняют чтобы проверить что изменение кода не привело к снижению производительности системы.
...
Рейтинг: 0 / 0
31.01.2010, 22:22
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441245
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
VoDAЕгоров АлександрВ общем и целом - описание бизнес-логики к языку программирования имеет слабое отношение. Тут соглашусь с iscrafm, чем более гибкий язык требуется для описания безнес-логики, тем хуже она спроектирована.Бизнес-логика далеко не всегда проектируется... бывает что она сложилась исторически и именно ее нужно реализовать. Заказчик платит именно за это.

проектируется реализация, пусть даже "сложившейся" бизнес-логики. Бывает конечно что и не проектируется, называется "что вижу, то и пишу"
...
Рейтинг: 0 / 0
31.01.2010, 23:02
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441254
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
VoDAiscrafmуточните плз, чем отличаются сущности Заказчик, Корпоративный заказчик, Средний, Маленький и т.п. в принципе и чем у них отличается процедура отправки счета, в частности.
С ХП это конечно не в тему, СУБД счета не отправляет.если вы хотите перенести БЛ на СУБД, то СУБД обязана отправлять счета. отправка счета это БЛ.
да, конечно. Отправка счета это элемент БЛ. Но не задача СУБД. Не стоит впадать в крайности. С одной стороны массовую обработку данных на Java писать, вместо SQL, а с другой стороны - отправлять электронную почту средствами сервера СУБД. Для этого есть сервер приложений или клиент.



VoDAiscrafmпопытался найти связь аудита действий пользователей с бизнес-логикой, сходу не получилось. Давайте более бизнес-логичные примеры обсуждать.эм... а почему аудит у вас не БЛ? Бизнес-логика это логика системы требуемая для работы компании. Т.е. по сути БЛ это ВСЕ что хочет получить заказчик и за что он платит.
потому что это из категории системных утилит.

VoDAiscrafmестественно не должна. Она и не знает. Банальная валидация ввода.Валидация ввода это тоже БЛ. И кто же должен ее реализовать? А главное ГДЕ?
где требуется. Диапазон от клиента до СУБД.
...
Рейтинг: 0 / 0
31.01.2010, 23:08
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441383
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
VoDAЕгоров АлександрВ общем и целом - описание бизнес-логики к языку программирования имеет слабое отношение. Тут соглашусь с iscrafm, чем более гибкий язык требуется для описания безнес-логики, тем хуже она спроектирована.Бизнес-логика далеко не всегда проектируется... бывает что она сложилась исторически и именно ее нужно реализовать. Заказчик платит именно за это.
Если для изменения БЛ Вам требуется изменение модулей системы и перекомпиляция проекта - значит при использовании Вашей методики получим систему, порождающую уникальные версии на каждом клиенте. И Вы утверждаете, что это методика упрощает поддержку? Я же говорю о подходе, когда "описание БЛ" - это отдельный от кода системы слой. Возможно также написанный на Java. Возможно на каком-нить BPEL. А возможно и просто структурированный текстовый набор деклараций. Тогда изменение БЛ вообще не потребует никаких ихменений кода системы, перекомпиляции и перетестирования.
VoDAЕгоров АлександрНа мой вкус, это некорректный пример. Ибо если аудит не включен в саму архитектуру изначально - без переделеки архитектуры это будут "примочки" и "извраты" разной степени сложности. Тут вступает в силу гибкость java как платформы для разработки. Если реализация требований заказчика вызывает "извраты" на уровне СУБД - значит они должны быть реализованы на другом уровне. Для java подобная навеска практически стандартная весчь.Стоп-стоп-стоп. Уровень СУБД ведь проектирует тоже автор системы, в Вашем случае - это либо Вы, либо Ваща система нагенерила этих извраты в СУБД. :) Либо давайте пример, как работает "практически страндартная весчь". На примере: справочник контрагентов с полями ИНН, ЮрАдрес и Телефоны. Одному клиенту аудит не нужен. В Вашей системе он и не закладывался. У другого - требование "Справочник Контрагенты должен обеспечить хранение предыдущих значений реквизитов и автора изменений"? Ваши действия в Вашей системе?

VoDAВот тут проявляется основная разница между DBA и разработчиками "серверного лагеря". Вы сидите в компании и у вас уже есть СУБД. Появление другой СУБД это явление очень редкое ибо требует много ЗАТРАТ на изменение.
Я сижу не только на СУБД, но и на УЖЕ РАБОТАЮЩЕЙ СИСТЕМЕ. Если в этой системе требуется какое-либо изменение - я обращусь к автору этой системы, а не будут покупать новую. :) При замене же системы, пускай даже системы учета - затарты на приобретение новой СУБД далеко не самые главные. Причем чем крупнее фирма, тем больше затрат ложится на "дописание бизнес-логики", переобучение пользователей и перенастройку процессов, чем на стоимость СУБД.
VoDAМы разрабатываем софт. У нас появление требования к продукту по поддержке еще одной СУБД - штатный запрос чтобы получить еще одного клиента и ЗАРАБОТАТЬ.Да зарабатывайте, пожалуйста. Я же не мешаю. :) Единственное пожелание - не закрывайте полностью уровень БД от доработки на местах. А то потом DBA мучаются с тормозами, а ничего поделать не могут. ;)

VoDAсмотрим на процент java и PL/SQL тынц
"The ratings are calculated by counting hits of the most popular search engines. The search query that is used is +"<language> programming". Статистика поисковых запросов неинтересна. Собственно тут я сам оплошал. Я имел ввиду "программистов информационных систем".

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

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

VoDAТак вынос БЛ в отдельный слой (на апп-сервер) и есть архитектурное решение.
...имеющие минусы в быстройдетсвии перед решениями, позволяющими оптимально "размазывать" БЛ по раздельным слоям. Но почему-то эти минусы очень фанатично отрицаются. В результате возникает ощущение, что выбор систем "только на Java и только с СП" обснуется методом "ибо кошерно!". Апологетов 1С, за такие обоснования почему-то принято ругать :) А ведь 1С - это тот же ORM, "все только на клиенте и СП", и "ни строчки SQL". ;)
...
Рейтинг: 0 / 0
01.02.2010, 05:55
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441423
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
VoDAspЯ считаю, что последним кто проверяет и действительно хранит все в целостном виде - база данных - все время в своих проектах использую контроль бизнес-правил на сервере БД, чтобы при их изменении не ковырять N-слоев и не иметь геморрой в случае если гдето обшибся в N-м слоек сожалению далеко не всегда СУБД знает что есть целостный вид данных. Конечно можно сделать проверку целостности типа "если товар имеет стоимость до 100 рублей (одна таблица) и введен в продажу до 31 декабря 2009 (другая таблица) и это разрешено менеджером (третья таблица), то разрешить продажу со скидкой до 5%".

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

Ваш пример - это "правило" разрешения продаж. Причем пример как раз подходящий для демонстрации преимущества хранения таких проверок в слое СУБД. Допустим, Ваше првило уже внедрено. Клиент захотел изменить это правило на "...а если клиент имеет статус Корпоративный (четвертая таблица), то разрешить продажу со скидкой 10%". При размещении этой функции в БД - нужно изменить код функции проверки продаж, оттестировать ее (в том числе и по нагрузке на сервер[а] СУБД) и отдать в продакшн. Поскольку клиент\\СП получает стандартный рекордест, содержащий описание и номер строки документа с ошибкой - никаких изменений на клиенте\\СП не требуется. Проверка выполняется непосредственно в СУБД - никаких изменений в производительности всей системы опять-таки нет, и при увеличившемся количестве проверок объем трафика СП<->БД остается неизменным.
Есть и декларативные споспобы описание таких проверок. (Iscrafm, где-то у Вас была картинка описания именно проверок, а не проведения. Покажите, пожалуйста. А то я в торопях не нашел). В этом случае все изменения СП сделает сам, и на всех необходимых слоях вообще без программирования.
В Вашем же случае как? Подправляем юнит, пересобираем систему, тестируем её опять всю целиком? Параллельно получаем "нестандартную" версию системы у конкретного клиента, к которой начинаем где-то помнить, что модуль такой-то изменен, в отличии от базовой версии?
...
Рейтинг: 0 / 0
01.02.2010, 08:32
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441531
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
iscrafmда, конечно. Отправка счета это элемент БЛ. Но не задача СУБД. Не стоит впадать в крайности. С одной стороны массовую обработку данных на Java писать, вместо SQL, а с другой стороны - отправлять электронную почту средствами сервера СУБД. Для этого есть сервер приложений или клиент.мужчина, а где вы увидели обработку данных на Java ВМЕСТО SQL? именно вместо? мы говорим о выносе БЛ на Java, сам же код БЛ вызывает SQL если требуется манипуляция с данными.

И вы говорите о наличии сервера приложения. Тогда зачем кроме сервера приложения делать еще один слой хранящий Бизнес-Логику?

iscrafmVoDAэм... а почему аудит у вас не БЛ? Бизнес-логика это логика системы требуемая для работы компании. Т.е. по сути БЛ это ВСЕ что хочет получить заказчик и за что он платит.
потому что это из категории системных утилит.заказчику пофигу как вы это называете. вам заплатили и вы ОБЯЗАНЫ реализовать функциональность.

Теперь вопрос какая архитектура выгоднее: 1. вариант сделать логику на СУБД + Апп-Сервере (поскольку СУБД не может отправлять эл.почту) + системную утилиту для аудита.
2. вынести всю бизнес-логику на АппСервер.

В каком случае меньше вероятность ошибок между слоями? Ведь не секрет, что ошибки чаще проявляются между компонентами, а не внутри самих компонент.
...
Рейтинг: 0 / 0
01.02.2010, 10:25
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441570
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
VoDAiscrafmда, конечно. Отправка счета это элемент БЛ. Но не задача СУБД. Не стоит впадать в крайности. С одной стороны массовую обработку данных на Java писать, вместо SQL, а с другой стороны - отправлять электронную почту средствами сервера СУБД. Для этого есть сервер приложений или клиент.мужчина, а где вы увидели обработку данных на Java ВМЕСТО SQL? именно вместо? мы говорим о выносе БЛ на Java, сам же код БЛ вызывает SQL если требуется манипуляция с данными.
Женщина, не нужно здесь крутить виражи, общаются специалисты. Речь шла об ООП реализации бизнес-логики. А SQL как-то не очень внисывается в эту категорию. Читайте внимательней о чем конкретно беседа идет.

VoDAiscrafmVoDAэм... а почему аудит у вас не БЛ? Бизнес-логика это логика системы требуемая для работы компании. Т.е. по сути БЛ это ВСЕ что хочет получить заказчик и за что он платит.
потому что это из категории системных утилит.заказчику пофигу как вы это называете. вам заплатили и вы ОБЯЗАНЫ реализовать функциональность.
Вы кто, менеджер по продажам что-ли? Так бы сразу и сказали. Неправильное понимание самой сути того, что называется бизнес-логикой и как в принципе системы проектируются и реализуются. Отсюда и все остальные невероятные выводы.


VoDAТеперь вопрос какая архитектура выгоднее: 1. вариант сделать логику на СУБД + Апп-Сервере (поскольку СУБД не может отправлять эл.почту) + системную утилиту для аудита.
2. вынести всю бизнес-логику на АппСервер.
В каком случае меньше вероятность ошибок между слоями? Ведь не секрет, что ошибки чаще проявляются между компонентами, а не внутри самих компонент.

(1). Вы же сами сказали, многие ошибки между слоями. Делить транзакцию БЛ между слоями более накладно. Понимаете что не секрет, а спрашиваете зачем-то
...
Рейтинг: 0 / 0
01.02.2010, 10:39
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441576
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
"Бизнес-логика — в разработке информационных систем — совокупность правил, принципов, зависимостей поведения объектов предметной области системы."

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

Мне кажется, что БЛ, влияющая на структуру объекта, должна быть максимально приближена к месту хранения этих объектов и быть максимально инкапсулирована.

Место же реализации прочей БЛ может изменяться в зависимости от типов и целей приложения и не должно иметь "модного" подхода.

Приведу пример:
пусть мы принимаем на работу курьера, наверное, целесообразно хранить данные текущей тарифной вилки (как довольно редко изменяемые) и допустимые диапазоны колебания внутри нее, устанавливаемые руководством, в таблицах базы .

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

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

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

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

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

---------------------------------------------------------------------------------------------------
Мне кажется, что попытки перенесения элементарных DML операций на уровень сервера приложений имеют только одно серьезное обоснование: попытка уйти от привязки к конкретной реализации СУБД и создать универсальное приложение.

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

Между прочим по этой же логике надо писать сервер приложений на 2-4 языках программирования, а вдруг у заказчика специалисты по С#, Delphi или C++ и им требуется развивать и дописывать отдельный функционал приложения (между прочим для серьезных систем стандартное требование к возможности поддержки и развития в довольно широких пределах своими силами, и учет при покупке системы на чем она написана совсем не шутка) и сделаны вложения в их обучение, а у нас сервер приложений на JAVA?

Интересно, что сам SQL создавался как попытка создать универсальный язык общения с СУБД и ухода от завязки на конкретного производителя.
Кончилось тем, что SQL мало того, что стал в основном языком разработчиков, так еще и изрядно пожертвовал своей универсальностью по требованию тех же разработчиков (особенно в части DDL), которым подавай то индексы по функциям и битовым картам, то аналитические функции, то FGAC.
...
Рейтинг: 0 / 0
01.02.2010, 10:45
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441587
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
Егоров АлександрТогда изменение БЛ вообще не потребует никаких ихменений кода системы, перекомпиляции и перетестирования.Может я чего не понимаю. Но как вы гарантируете работоспособность системы БЕЗ юнит-тестирования внесенных изменений? Допустим ваше изменение затронуло только BPEL. Как вы проверили что для заданных условий новая BPEL-логика дает правильный ответ?
Егоров АлександрСтоп-стоп-стоп. Уровень СУБД ведь проектирует тоже автор системы, в Вашем случае - это либо Вы, либо Ваща система нагенерила этих извраты в СУБД. :) Либо давайте пример, как работает "практически страндартная весчь". На примере: справочник контрагентов с полями ИНН, ЮрАдрес и Телефоны. Одному клиенту аудит не нужен. В Вашей системе он и не закладывался. У другого - требование "Справочник Контрагенты должен обеспечить хранение предыдущих значений реквизитов и автора изменений"? Ваши действия в Вашей системе?подключаю к проекту Hibernate Envers, на сущьность "Справочник Контрагенты" ставлю @Audited, делаю перехватчик и в нем заполняю поле "кто сделал изменение".

Компайл, коммит на сервер, автоматическая сборка и проверка юнитами.

Егоров АлександрЯ сижу не только на СУБД, но и на УЖЕ РАБОТАЮЩЕЙ СИСТЕМЕ. Если в этой системе требуется какое-либо изменение - я обращусь к автору этой системы, а не будут покупать новую. :) При замене же системы, пускай даже системы учета - затарты на приобретение новой СУБД далеко не самые главные. Причем чем крупнее фирма, тем больше затрат ложится на "дописание бизнес-логики", переобучение пользователей и перенастройку процессов, чем на стоимость СУБД. так ко мне и обратишься клиенты не переходят на другие СУБД ибо это дорого отнюдь не потому что нужно купить лицензий. Нужно еще обучить админов и т.п.

Егоров АлександрДа зарабатывайте, пожалуйста. Я же не мешаю. :) Единственное пожелание - не закрывайте полностью уровень БД от доработки на местах. А то потом DBA мучаются с тормозами, а ничего поделать не могут. ;)возможность доработки приложения компанией-заказчиком это либо если ПО изначально OpenSource либо стоит НАМНОГО дороже обычной лицензии. Чаще всего заказчик не хочет платить за возможность доработки ПО своими разрабами.

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

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

Егоров АлександрVoDAТак вынос БЛ в отдельный слой (на апп-сервер) и есть архитектурное решение.
...имеющие минусы в быстройдетсвии перед решениями, позволяющими оптимально "размазывать" БЛ по раздельным слоям. Но почему-то эти минусы очень фанатично отрицаются.минусов в быстродействии SQL - нет ибо Java выдает тот же SQL, что и ХП. Разница в скорости только в случаях массовой обработки данных БЕЗ сложной логики. Тут согласен

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

Опять же начинаются ситуации когда вроде как и можно вынести что-то на СУБД, но поддержка "размазанной логики" выйдет дороже.
...
Рейтинг: 0 / 0
01.02.2010, 10:47
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441599
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
Егоров АлександрПроверка выполняется непосредственно в СУБД - никаких изменений в производительности всей системы опять-таки нетвот тут фундаментальная ошибка. в системах в которых скорость работы принципиальна есть правило, что любое изменение кода вызывает деградацию пока не доказано обратное. И прогонка юнитов на кластере есть как раз доказательство того, что скорость не уменьшилась.

Егоров АлександрПодправляем юнит, пересобираем систему, тестируем её опять всю целиком? Параллельно получаем "нестандартную" версию системы у конкретного клиента, к которой начинаем где-то помнить, что модуль такой-то изменен, в отличии от базовой версии?а если мы внесли изменения в ХП это не будет ""нестандартную" версию системы у конкретного клиента, к которой начинаем где-то помнить, что ХП такой-то изменен, в отличии от базовой версии?"
...
Рейтинг: 0 / 0
01.02.2010, 10:52
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441626
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
2 iscrafm

Пожалуй вот это высказывание наиболее точно указывает на разницу в подходах.
carperТут кроется противоречие - заказчику очень редко нужна универсальность, универсальность нужна разработчику, чтобы увеличить продажи.
Поскольку одному нужен пылесос, а другому швабра, разработчики привязывают пылесос к швабре и удивляется почему одни жалуются на то, что швабра слишком тяжелая и занимает много места, а другие на то, что им очень мешает пылесосить деревянная палка и тряпку постоянно засасывает в пылесос.+1
...
Рейтинг: 0 / 0
01.02.2010, 10:58
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441641
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
VoDA какое изменение БЛ может быть в момент внедрения? В момент внедрения любые изменения БЛ уже завершены и заказчик получает результат. Если требуются еще изменения БЛ, то идет новый контракт и новая разработка + новое внедрение.

Вы это только в слух не говорите в серьезном обществе.

VoDA Вот только оптимальное "размазывание" логики по слоям чаще всего дороже в разработке, чем плюхнуть всю БЛ на АппСервер. И заказчик и разработчик хотят уменьшить стоимость решения, потому принимается более дешевый вариант с приемлемой скоростью работы.Опять же начинаются ситуации когда вроде как и можно вынести что-то на СУБД, но поддержка "размазанной логики" выйдет дороже.
Вы с чем сравнивали? Или это воспринимать как "личное мнение, основанное на анализе только своей же работы"? Допустим я говорю, что ничего не выходит дороже и быстрее в разы. Несколько раз давал ссылку на документ, можете поискать.
...
Рейтинг: 0 / 0
01.02.2010, 11:03
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441648
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
VoDA 2 iscrafm

Пожалуй вот это высказывание наиболее точно указывает на разницу в подходах.
carperТут кроется противоречие - заказчику очень редко нужна универсальность, универсальность нужна разработчику, чтобы увеличить продажи.
Поскольку одному нужен пылесос, а другому швабра, разработчики привязывают пылесос к швабре и удивляется почему одни жалуются на то, что швабра слишком тяжелая и занимает много места, а другие на то, что им очень мешает пылесосить деревянная палка и тряпку постоянно засасывает в пылесос.+1
т.е. Вы признаете, что находитесь в погоне за универсальностью. Страннно. Тогда смысл Ваших постов становится еще более непонятным. Говорите что это плохо, но отстаиваете. Я понимаю, типа работа такая, но....
...
Рейтинг: 0 / 0
01.02.2010, 11:06
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441754
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
Разобъю пост. А то больно неудобно отвечать :)
VoDAЕгоров Александр ...нужно изменить код функции проверки продаж, оттестировать ее (в том числе и по нагрузке на сервер[а] СУБД) и отдать в продакшн... Тогда изменение БЛ вообще не потребует никаких ихменений кода системы, перекомпиляции и перетестирования.Может я чего не понимаю. Но как вы гарантируете работоспособность системы БЕЗ юнит-тестирования внесенных изменений? Допустим ваше изменение затронуло только BPEL. Как вы проверили что для заданных условий новая BPEL-логика дает правильный ответ?
Поправил отцитированное Вами, чтобы было понятно. Я протестировал изменения. Эти изменения не затрагивают остальную систему, тестировать всю систему нет никакой необходимости. Проверка эта была автоматизирована добавлением в существующий тестовый набор данных докуентов, проверяющих дополнительные варианты условий, процедура прогнана по ним, сверены как результаты процедуры, так и изменение производительности. Остальная часть системы никак не затронута изменениями, так как и вход, и выход этой процедуры не изменился.
...
Рейтинг: 0 / 0
01.02.2010, 11:45
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441816
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
VoDAЕгоров АлександрСтоп-стоп-стоп. Уровень СУБД ведь проектирует тоже автор системы, в Вашем случае - это либо Вы, либо Ваща система нагенерила этих извраты в СУБД. :) Либо давайте пример, как работает "практически страндартная весчь". На примере: справочник контрагентов с полями ИНН, ЮрАдрес и Телефоны. Одному клиенту аудит не нужен. В Вашей системе он и не закладывался. У другого - требование "Справочник Контрагенты должен обеспечить хранение предыдущих значений реквизитов и автора изменений"? Ваши действия в Вашей системе?подключаю к проекту Hibernate Envers, на сущьность "Справочник Контрагенты" ставлю @Audited, делаю перехватчик и в нем заполняю поле "кто сделал изменение".

Компайл, коммит на сервер, автоматическая сборка и проверка юнитами.
Плюс "** Extra care is required if your use-case has this requirement. My recommendation is to let Envers initially creates audit tables for your auditable entities, reengineer audit tables db schema, do required modifications e.g. changing audit tables suffixes, make necessary changes in hibernate config (e.g. disable auto creation of audit tables, configure Envers to use user created audit table), and finally build, deploy and test your application. " (с) отсюда ...

То есть опять скомпилить новую версию системы. И если клиент отказывается - опять все заново? Только уже "отключаю... убираю @Audited... и т.д..." ?

Скажите, у Вас большая служба поддержки? Что происходит у Вас, когда одному клиенту внедрена система с аудитом, а другому - без?
...
Рейтинг: 0 / 0
01.02.2010, 12:06
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441831
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
VoDAЕгоров АлександрВот в этом у нас принципиальное непонимание. Любое изменение БЛ не должно требовать вообще изменения кода системы. Иначе это неправильная система. Или прикажете ходить на внедрение со средой разработки, отладчиками и тестироващиками?А какое изменение БЛ может быть в момент внедрения? В момент внедрения любые изменения БЛ уже завершены и заказчик получает результат. Если требуются еще изменения БЛ, то идет новый контракт и новая разработка + новое внедрение.
Ой! Вы это серьезно? Можно примерные расценки, сколько будет стоить новый контракт + новая разработка + новое внедрение в ситуации "...а если клиент имеет статус Корпоративный (четвертая таблица), то разрешить продажу со скидкой 10%" ?
...
Рейтинг: 0 / 0
01.02.2010, 12:11
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441861
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
VoDAЕгоров АлександрЯ сижу не только на СУБД, но и на УЖЕ РАБОТАЮЩЕЙ СИСТЕМЕ. Если в этой системе требуется какое-либо изменение - я обращусь к автору этой системы, а не будут покупать новую. :) При замене же системы, пускай даже системы учета - затарты на приобретение новой СУБД далеко не самые главные. Причем чем крупнее фирма, тем больше затрат ложится на "дописание бизнес-логики", переобучение пользователей и перенастройку процессов, чем на стоимость СУБД. так ко мне и обратишься клиенты не переходят на другие СУБД ибо это дорого отнюдь не потому что нужно купить лицензий. Нужно еще обучить админов и т.п.
Я не смогу уговорить боссов на покупку системы, которая на каждый чих потребует "новый контракт+новая разработка+новое внедрение". У нас гибкий бизнес. Правила меняются достаточно часто, особенно скидки, и ограниченения по ним. :)

VoDAЕгоров АлександрДа зарабатывайте, пожалуйста. Я же не мешаю. :) Единственное пожелание - не закрывайте полностью уровень БД от доработки на местах. А то потом DBA мучаются с тормозами, а ничего поделать не могут. ;)возможность доработки приложения компанией-заказчиком это либо если ПО изначально OpenSource либо стоит НАМНОГО дороже обычной лицензии. Чаще всего заказчик не хочет платить за возможность доработки ПО своими разрабами.
Вот тут у нас тоже какое-то принципиальное расхождение. Я видел достаточно много хороших программ, которые успешно внедрились, какое-то время успешно проработали, а потом пришел момент меняться - и суммы "нового контракта" оказались больше, чем переход на более худшую систему, но с возможностью собственной доработки. И всегда считал, что чем гибче бизнес компании, тем выгоднее иметь своего ИТ-специалиста на поддержке.
...
Рейтинг: 0 / 0
01.02.2010, 12:23
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441934
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
VoDAЕгоров АлександрVoDAТак вынос БЛ в отдельный слой (на апп-сервер) и есть архитектурное решение.
...имеющие минусы в быстройдетсвии перед решениями, позволяющими оптимально "размазывать" БЛ по раздельным слоям. Но почему-то эти минусы очень фанатично отрицаются.минусов в быстродействии SQL - нет ибо Java выдает тот же SQL, что и ХП. Разница в скорости только в случаях массовой обработки данных БЕЗ сложной логики. Тут согласен
Только ХП не гоняет ни сам этот SQL, ни результаты его исполения по сети. Hibernate, насколько я знаю, не формирует динамических хранимок для получения сложного и многообъектного фильтра, а вытягивает все необходимые данные и обрабатывает их сам. На СП.

Массовая обработка данных - это, например, поток заявок покупателя, каждую позицию которых нужно проверить на корректность скидки? Представляете какой трафик поднимется между СП и БД, если таких заявок забивается тысячи в день, и в среднем состоят из десятков позиции, а некоторые и до сотни? ;)

VoDAВот только оптимальное "размазывание" логики по слоям чаще всего дороже в разработке, чем плюхнуть всю БЛ на АппСервер. И заказчик и разработчик хотят уменьшить стоимость решения, потому принимается более дешевый вариант с приемлемой скоростью работы.
Опять же начинаются ситуации когда вроде как и можно вынести что-то на СУБД, но поддержка "размазанной логики" выйдет дороже.
Не обидеть ради. Так если Вы под каждый контракт пишите новый проект - тогда действительно дороже. Особенно с учетом, что Вам за каждое изменение будут платить. Понятно, что деньги нужны всем. Но вроде как рынок дает основания считать, что больше всего денег зарабатывают те, кто создает всякие фреймворки (конфигураторы, конструкторы, платформы и т.д.) и базовый бизнес-функционал в качестве демонстрации возможностей. Думаю, архитектурыне вопросы очень сильно зависят от того, разработкой каких именно систем заниматься. Это, кстати, тоже может быть причиной непонимания друг-друга... :)
...
Рейтинг: 0 / 0
01.02.2010, 12:49
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36441942
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
iscrafmVoDA какое изменение БЛ может быть в момент внедрения?
Вы это только в слух не говорите в серьезном обществе.как скажешь

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

iscrafmт.е. Вы признаете, что находитесь в погоне за универсальностью. Страннно. Тогда смысл Ваших постов становится еще более непонятным. Говорите что это плохо, но отстаиваете. Я понимаю, типа работа такая, но....я стараюсь понять почему большие приложения чаще пишутся применяя АппСервер, а не внутри СУБД. Тот же 1С или MS Axapta в качестве примера.
...
Рейтинг: 0 / 0
01.02.2010, 12:52
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36442015
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
VoDAiscrafmВы с чем сравнивали? Или это воспринимать как "личное мнение, основанное на анализе только своей же работы"? Допустим я говорю, что ничего не выходит дороже и быстрее в разы. Несколько раз давал ссылку на документ, можете поискать.Это мое размышление на тему почему у нас заказывают ПО и в нем чаще всего фигурирует АппСервера (а не голые СУБД) + личное мнение основанное на анализе работы моей компании - достаточно большого вендора ПО и интегратора.

стоп! а кто говорил о голой СУБД без апп-сервера? С моей стороны было бы нелогично, учитывая что моя компания выпускает 3-звенную платформу и все проекты делает на ней. :) Речь, насколько я помню, идет о реализации бизнес-логики. Центром является APP сервер. Он и распределяет, какой фрагмент выполнить средствами СУБД, а какой другим способом.
...
Рейтинг: 0 / 0
01.02.2010, 13:17
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36442057
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
VoDAЕгоров АлександрПроверка выполняется непосредственно в СУБД - никаких изменений в производительности всей системы опять-таки нетвот тут фундаментальная ошибка. в системах в которых скорость работы принципиальна есть правило, что любое изменение кода вызывает деградацию пока не доказано обратное. И прогонка юнитов на кластере есть как раз доказательство того, что скорость не уменьшилась.Вы, когда меняете колесо у машины, ТО двигателя делаете? ;) Я же показывал - измения тестировались в том числе и на производительность. Ничто не мешает тестовый набор подготовить так, чтобы провести еще и стресс-тест. Но обычно достаточно анализа плана выполнения ХП и оценки изменения времени ее выполнения.

VoDAЕгоров АлександрПодправляем юнит, пересобираем систему, тестируем её опять всю целиком? Параллельно получаем "нестандартную" версию системы у конкретного клиента, к которой начинаем где-то помнить, что модуль такой-то изменен, в отличии от базовой версии?а если мы внесли изменения в ХП это не будет ""нестандартную" версию системы у конкретного клиента, к которой начинаем где-то помнить, что ХП такой-то изменен, в отличии от базовой версии?"
Ну, поскольку Вы не можете ответить по своей архитектуре, отвечу по своей :) Базовая архитектура содержит метод CheckRequest(), протокол взаимодействия с процедурами СУБД (на входе процедуры - ID документа, на выходе - фиксированная таблица конфликтов и предупреждений), поцедуры-заглушки, написанные на нужном диалекте SQL и минимальный функционал, определяющий "ошибка выполнения" как непустой датасет после выполнения процедуры, и умеющий выводить принятую таблицу ошибок пользователю. Тем самым, одна и таже версия системы, работает с разной бизнес-логикой проверки качества заявки покупателя. Еще чуть-чуть поднапрячься - и текст ХП можно будет компилировать по декларативному набору правил, который уже сам пользователь сможет настраивать и менять под изменения своего бизнеса.
...
Рейтинг: 0 / 0
01.02.2010, 13:29
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36442103
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
carper,

Практически полностью согласен с Вами.

Замечу лишь, что хорошей архитектуры мало, для хороших продаж. А хороший маркетинг сможет хорошо продавать и не очень хорошую архитектуру :) И получается, что пока находишься на стороне "внутреннего разработика", можно и вылизать архитектуру, и оптимизировать быстродействие, и критиковать чужие разработки. :) Но когда собственноручно созданный продукт начинаешь продавать - главным уже становится далеко не качество архитектуры, а объем продаж. Тюнингом можно заниматься снова, если получится подняться и прочно выйти на рынок - тогда архитектурные изыски можно предлагать как конкурентное преимущество перед другими продуктами. :)
...
Рейтинг: 0 / 0
01.02.2010, 13:48
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36442167
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Егоров Александркогда собственноручно созданный продукт начинаешь продавать - главным уже становится далеко не качество архитектуры, а объем продаж. Тюнингом можно заниматься снова, если получится подняться и прочно выйти на рынок - тогда архитектурные изыски можно предлагать как конкурентное преимущество перед другими продуктами. :)
Александр, есть одна деталь, напрямую связанная с архитектурой - стоимость поддержки. Она может быть такой, что всю выручку будет "съедать". Поэтому, архитектуру считаю одним из приоритетов еще до выпуска продукта на рынок. Тяжело и накладно поддерживать заплатки или переделки в случае промаха в самом начале.

p.s. картинки о которых Вы говорили на пред. странице, с ходу не нашел, к сож.
...
Рейтинг: 0 / 0
01.02.2010, 14:07
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36442187
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
Егоров АлександрЯ не смогу уговорить боссов на покупку системы, которая на каждый чих потребует "новый контракт+новая разработка+новое внедрение". У нас гибкий бизнес. Правила меняются достаточно часто, особенно скидки, и ограниченения по ним. :)Тогда вам выгоднее получить / сделать систему типа ERP имеющую свой встроенный язык- к примеру AX или 1С.

Но вряд ли вы сможете сделать чтобы система работала быстро (скомпилированный код) и вы могли полностью менять ее поведение. В тех же ERP менять поведение системы можно, но в разрешенных разработчиком рамках.
...
Рейтинг: 0 / 0
01.02.2010, 14:13
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36442210
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
Егоров АлександрМассовая обработка данных - это, например, поток заявок покупателя, каждую позицию которых нужно проверить на корректность скидки? Представляете какой трафик поднимется между СП и БД, если таких заявок забивается тысячи в день, и в среднем состоят из десятков позиции, а некоторые и до сотни? ;) согласен, что оперирование массивом данных проще на СУБД.

Могу даже добавить что мат.операции над байтами (когда по массиву байт пройтись и увеличить на единицу) намного быстрее сделать на С/С++, а не java. Из-за дополнительных проверок введенных в java.

Егоров АлександрНо вроде как рынок дает основания считать, что больше всего денег зарабатывают те, кто создает всякие фреймворки (конфигураторы, конструкторы, платформы и т.д.) и базовый бизнес-функционал в качестве демонстрации возможностей. Думаю, архитектурыне вопросы очень сильно зависят от того, разработкой каких именно систем заниматься. Это, кстати, тоже может быть причиной непонимания друг-друга... :)Мы делаем любые системы Вот пару лет назад нам аутсорсили софт для формацевтических лабораторий, а в прошлом году эм... софт для голосового управления / помощи работникам складов перепиливали под нужды ... сортировочного цеха. Системы совсем не связанные друг с другом. Только принципы остаются общие, да написаны на одних и тех же фреймворках (Java) + требуют одинаковые сервера.
...
Рейтинг: 0 / 0
01.02.2010, 14:21
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36442251
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
iscrafmстоп! а кто говорил о голой СУБД без апп-сервера? С моей стороны было бы нелогично, учитывая что моя компания выпускает 3-звенную платформу и все проекты делает на ней. :) Речь, насколько я помню, идет о реализации бизнес-логики. Центром является APP сервер. Он и распределяет, какой фрагмент выполнить средствами СУБД, а какой другим способом.тогда нам проще будет найти точки взаимодействия.

Выгода для производителя выносить логику на АппСервер:
1. дешевле нанять разработчиков на одном языке (АппСервера) чем на нескольких (АппСервер) + СУБД.
2. независимость от СУБД делает продукт более конкуренто-способным на большинстве рынков. Т.к. больше покупателей.
3. *сейчас только подумал* закрытость кода вынуждает заказчиков покупать саппорт или платить дополнительно за доводку системы.
4. бОльшее количество задач может быть решено на уровне АппСервера, а не СУБД. СУБД не годится ни для чего кроме оперирования персистными данными.

Опять же в совсем больших системах с сотнями апп-серверов переносить БЛ с Апп на СУБД... ИМХО убьет производительность.
...
Рейтинг: 0 / 0
01.02.2010, 14:35
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36442263
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
Егоров Александрcarper,

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

"Сир, штыки годятся для чего угодно, кроме одного - на них нельзя усидеть". ( (С) Толейран )

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

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

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


Есть, разумеется, еще чисто российский путь, когда некая система навязывается гос. органами, но тут уж о какой архитектуре речь :(
...
Рейтинг: 0 / 0
01.02.2010, 14:38
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36442363
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
Повторить финт ушами, который делают производители продуктов питания, просто отказываясь от дискредитировавшей себя торговой марки и переходя на другую, особо не удастся, все же слишком разные жизненные циклы и затраты.А по моему это вполне справедливо и для ПО
...
Рейтинг: 0 / 0
01.02.2010, 15:04
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36442504
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
LSV,автор
А по моему это вполне справедливо и для ПО

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

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

(Это минимальная "норма" для отечественных производителей продуктов "широкого потребления", которым и производить-то ничего не надо, всякие там Доярушки, Злато и прочее вообще из отечественного имеют только шрифт на этикетке, цены в рублях и подход к качеству при закупке)
...
Рейтинг: 0 / 0
01.02.2010, 15:58
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36442526
skmdeveloper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skmdeveloper
Участник
carperЕсть, разумеется, еще чисто российский путь, когда некая система навязывается гос. органами, но тут уж о какой архитектуре речь :(

Извините, но это из области мифологии неудачников. Вот в нашем городе усиленно проталкивали Парус, финансировали это мероприятие из бюджета, ухлопали нормальные деньги. Выхлоп (количество внедрений) = 0. Все кто работают, используют 1С. Пробовали накоторые структуры насильно внедрить "БЭСТ" - то же самое. Количество внедрений = 0.

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

ПО 1С не лучшее ни по какому параметру, но наилучшее по их совокупности.
...
Рейтинг: 0 / 0
01.02.2010, 16:06
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36442712
alneo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alneo
Участник
После появления ORM (nHibernate и EF) в мире .Net использую только DDD модель. Никакой логики на клиенте или бд.
Свято верю, что бизнес-логика должна лежать в бизнес-слое, возможно частично в сервисном(API).
А старые приложение где логика была на клиенте и/или в субд (на хранимках, констрейнтах и особо тригера) вспоминаю как страшный сон.
...
Рейтинг: 0 / 0
01.02.2010, 17:12
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36442757
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
alneoСвято верю, что бизнес-логика должна лежать в бизнес-слое, возможно частично в сервисном(API).Аминь!
...
Рейтинг: 0 / 0
01.02.2010, 17:26
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36442856
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
iscrafmАлександр, есть одна деталь, напрямую связанная с архитектурой - стоимость поддержки.Какая такая поддержка? :) Сказано же - "новый контракт + новая разработка + новое внедрение" ;)
Вопросы про поддержку я задавал тут , тут и тут. Ответов пока нет :)

А так я с Вами согласен полностью. Даже считаю, что промахи в архитектуре вообще нельзя искоренить заплатками. Особенно если промах в архитектуре - это отсутствие возможности устанавливать заплатки. :)
...
Рейтинг: 0 / 0
01.02.2010, 18:00
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36442894
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
skmdevelopercarperЕсть, разумеется, еще чисто российский путь, когда некая система навязывается гос. органами, но тут уж о какой архитектуре речь :(

Извините, но это из области мифологии неудачников.

Во-первых, почему это вы сразу решили, что я про 1С ? :)
Разве такая уважаемая компания, как 1С может позволить себе навязывание столь нечистоплотными методами ?
Я, кое-где упомянал 1С, но нигде не говорил про ее ангажированность, или я ошибаюсь?
Можно небольшую цитату из моих сообщений?

Может я про сбербанковский Банк Клиент, или программу проверки отчетности при сдаче оной в пенсионный фонд?
Вы видели это чудо в перьях (последний год значительно лучше, но прежние версии ...) ?


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

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

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

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

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

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

В-третьих, вы усмотрели в 1С какое-то интересное решение относящиеся к теме данного топика, или так, заступиться решили, услышав про некие нехорошие фирмы?


авторПО 1С не лучшее ни по какому параметру,
- Не верно, как минимум, оно лучшее по оперативности отражения изменений в российском законодательстве, лучшее по маркетингу и лидер по числу (не качеству) независимых решений созданных под ее эгидой.
...
Рейтинг: 0 / 0
01.02.2010, 18:23
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36442928
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
VoDAЕгоров АлександрМассовая обработка данных - это, например, поток заявок покупателя, каждую позицию которых нужно проверить на корректность скидки? Представляете какой трафик поднимется между СП и БД, если таких заявок забивается тысячи в день, и в среднем состоят из десятков позиции, а некоторые и до сотни? ;) согласен, что оперирование массивом данных проще на СУБД.
А я говорю не о массиве. Я говорю о нормальной рабочей ситуации - рабочий поток документов. Просто их много, они приходят из разных мест и упираются в СП. Ведь всё у нас делает он, и проверкой, и "проведением", и "пересчетом итогов", и получением данных для отчетов, и т.д. и т.п.... А СУБД просто занимается хранением данных в более удобном виде, чем куча отдельных dbf-ов, и возможностью бакапить эти данные в онлайне.

VoDAВот пару лет назад нам аутсорсили софт для формацевтических лабораторий, а в прошлом году эм... софт для голосового управления / помощи работникам складов перепиливали под нужды ... сортировочного цеха. Системы совсем не связанные друг с другом. Только принципы остаются общие, да написаны на одних и тех же фреймворках (Java) + требуют одинаковые сервера.
Ну как я и думал - разработка на заказ. И никаких тиражных систем "для среднего бизнеса". Везет Вам. :)
Собсно и вопросы про поддержку тогда снимаются - у Вас просто не может возникнуть ситуации, когда один проект разваливается на две ветки из-за прихоти клиентов :)
...
Рейтинг: 0 / 0
01.02.2010, 18:42
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36442999
skmdeveloper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skmdeveloper
Участник
В 1С в основном вся логика на клиенте. С точки зрения производительности (да и со многих прочих) это не оптимальный вариант.
Но есть одно "но", решающее для пользователя.
ПО без ошибок не бывает, тот кто утверждает обратное, мягко говоря лукавит. Но если в случае реализации логики в клиентской части найти ошибку, используя отладчик, и даже устранить ее может человек немного разбирающийся в программировании (я лично такой, не более), то в случае бизнес-логики на сервере это разгрести может только программист-гуру или скорее всего только тот, кто это написал.
Столкнется с этим пользователь у кого под рукой нет гуру от программирования, а это почти весь мелкий и средний бизнес и плюнет на недостатки в функционале и заточенности под его бизнес и выберед средненькое, попсовое, но по крайней мере работает.
Так что в большинстве случаев бизнес-логика на стороне клиента, по моему мнению наилучшее. Современные компьютеры уже достаточно мощные для этого.
...
Рейтинг: 0 / 0
01.02.2010, 19:17
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443066
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
VoDAОпять же в совсем больших системах с сотнями апп-серверов переносить БЛ с Апп на СУБД... ИМХО убьет производительность.Давайте немного посчитаем. Огрубим понятие "трафик" до "запрос" и возьмем наш пример с проверками на скидки. Будем считать, что документ проверку пройдет. Обработка ошибок нам сейчас непринципиальна. Возьмем вырожденный случай - Клиент выписал 1 заявку с 1 позицией в ней.

Вариант с логикой проверки и обработки на СП:
1. Клиент->СП = 2 запроса (передача заголовка заявки+строки товар\количество).
2. СП -> БД = запрос из "Таблица стоимости товара" по @ID
3. БД -> СП = Стоимость товара @ID
4. СП -> БД = запрос из "Таблица ввода товара впродажу"
5. БД -> СП = Дата ввода товара
6. СП -> БД = запрос из "Таблица разререшений менеджеров по товару"
7. БД -> СП = Флаг разрешения менеджера по товару @ID
8. СП -> БД = запрос из "Таблица свободных остатков по товару"
9. БД -> СП = количество свободных остатков
тут СП убедился, что по текущей БЛ заявку можно принять.
11. СП -> БД = 2 запроса (записать шапку заяки + записать строку товар\количество)
тут СП резервирует товар по текущей БЛ
12. СП -> БД = 1 запрос ("уменьшить количество свободных остатков")
13. СП -> Клиент= "Заявка принята".
"Трафик СП<->БД" = " Д окументов" * (2 + 11 * " С трок").

Вариант с логикой проверки и обработки на БД:
1. Клиент->СП = 2 запроса (передача заголовка заявки+строки товар\количество).
2. СП -> БД = 2 запроса (заголовок+строка).
4. СП -> БД = exec RequestCheck(@IDDOC)
5. БД -> СП = Check passed. No Errors found.
6. СП -> БД = exec RequestApply(@IDDOC)
7. БД -> СП = Request applied successfully.
8. СП -> Клиент = "Заявка принята".
"Трафик СП<->БД" = Д * (1 + С + 6) .

Пускай в день выписывается 1000 заявок по 20 строк в каждой.
Вариант 1 = 1000*(2+11*20) = 222000 "запросов"
Вариант 2 = 1000*(1+20+6) = 27000 "запросов".

Теперь добавляем условие "...а если клиент...":

Вариант 1. Добавляются запросы
7.1 СП -> БД = запрос из "Таблица контрагентов"
7.2 БД -> СП = Тип контаргента @ID
Формула меняется на Д * (2 + 13 * С). Дневной трафик увеличивается до 262000 "запросов"

Вариант 2. Ничего не добавляется и трафик остается неизменным.

Меняем документооборот на 1000 заявок по 50 строк:
Вариант1: 1000*(2+13*50)=652000 "запросов"
Вариант2: 1000*(1+50+6)=57000 "запросов"

Понимаю, что цифры эти не более чем "попугаи", но стоит подумать о разнице нагрузки на порядок и геометрическую зависимость от сложности БЛ. Кластер из "сотни Апп-серверов" нас, конечно, выручит. ;) Но ведь кластер - это не только серверное железо, это еще и внешние дисковые массивы, и сверхскоростные межсерверные коммуникации. А это тянет за собой грамотного админа, дорогостоящего помещения с вентиляцией и кондиционированием. Да и бесперебойное питание всему эту делу понадобится немаленкое...

И все потому, что разработчику невыгодно держать в штате БД-программиста?.. ;)
...
Рейтинг: 0 / 0
01.02.2010, 20:02
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443102
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
skmdeveloperВ 1С в основном вся логика на клиенте. С точки зрения производительности (да и со многих прочих) это не оптимальный вариант.
Уже можно в 1С тот же самый код клиента выполнять и на сервере приложений. Не без ньюансов, но можно. Правда, на работу платформы с БД это никак не сказывается :)
...
Рейтинг: 0 / 0
01.02.2010, 20:18
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443120
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
alneoСвято верю, что бизнес-логика должна лежать в бизнес-слое, возможно частично в сервисном(API).
Для нача определитесь что зверь такой бизнес-слой. Tier vs Layer многие путают.
...
Рейтинг: 0 / 0
01.02.2010, 20:27
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443128
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
skmdeveloperв случае реализации логики в клиентской части найти ошибку, используя отладчик, и даже устранить ее может человек немного разбирающийся в программировании (я лично такой, не более), то в случае бизнес-логики на сервере это разгрести может только программист-гуру или скорее всего только тот, кто это написал.

кто о чем, а мы про грибы.
...
Рейтинг: 0 / 0
01.02.2010, 20:29
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443196
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
iscrafmalneoСвято верю, что бизнес-логика должна лежать в бизнес-слое, возможно частично в сервисном(API).
Для нача определитесь что зверь такой бизнес-слой. Tier vs Layer многие путают.
Это же верующий человек! :) Определяться - это же от лукавого! :)

Странно только, почему апологеты "объктной бизнес-логики" в большинстве случаев используют именно РСУБД. При этом активно отрицая их возможности, делая из них простые "dbf-помойки", лепя костыли из ORMа и удивляясь, что это оно так медленно работает... Вместо использования готовых ООБД, которые под это дело самое оно и не нужно никаких костылей? Неужели только потому, что в MSVS нет нормально драйвера для Cache, а для MSSQL есть? ;) Или потому, что в Java о поддержки того же Cache что-то вообще не слыхать? :)
...
Рейтинг: 0 / 0
01.02.2010, 21:34
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443239
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Егоров Александр
Вариант1: 1000*(2+13*50)=652000 "запросов"
Вариант2: 1000*(1+50+6)=57000 "запросов"
Все отлично. А теперь учтите, что все запросы из варианта 1 нужно выполнять и в варианте 2. Отличие только в том, что по сети их гонять не надо. И так имеем:
"Нагрузка" на сервер базы данных:
Вариант 1. 652000
Вариант 2. 709000 + еще некая математика
"Нагрузка" на сеть:
Вариант 1. 652000
Вариант 2. 57000
Остается только сравнить "пропускную способность" сети и сервера базы данных и понять в каком из двух вариантов мы раньше "упремся". Вряд ли ответ столь очевиден.
...
Рейтинг: 0 / 0
01.02.2010, 22:17
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443250
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Егоров АлександрСтранно только, почему апологеты "объктной бизнес-логики" в большинстве случаев используют именно РСУБД.Знаете любителе выпить пива на футболе вполне адекватно воспринимают кофе по утрам. Вас это не удивляет?
Умные люди для разных задач используют разные инструменты. Для реализации бизнес-логики одни, для хранения данных - другие. И для каждой задачи стараются выбрать наиболее подходящий инструмент.
...
Рейтинг: 0 / 0
01.02.2010, 22:29
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443257
skmdeveloper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skmdeveloper
Участник
iscrafmskmdeveloperв случае реализации логики в клиентской части найти ошибку, используя отладчик, и даже устранить ее может человек немного разбирающийся в программировании (я лично такой, не более), то в случае бизнес-логики на сервере это разгрести может только программист-гуру или скорее всего только тот, кто это написал.

кто о чем, а мы про грибы.
Я о реальной жизни а не о грибах. ПО, какими бы замечательными характеристиками не обладало, но вокруг которого обязательно должны бегать с бубном SQL-гуру и еще толпа узких специалистов, обязательно будет занимать мизерную долю на рынке, за исключением специфических случаев - обработки больших объемов информации, высоконагруженных систем и т.д. И тем дальше, тем эта тенденция будет сильнее.
Потребительские качества продукта важнее всех остальных вместе взятых.
...
Рейтинг: 0 / 0
01.02.2010, 22:34
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443307
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Bogdanov Andrey...для реализации бизнес-логики одни, для хранения данных - другие. И для каждой задачи стараются выбрать наиболее подходящий инструмент.
думаю, что основная нить этого спора (или милой беседы) как раз в том, чтобы исключить крайности. Реализовать всю БЛ только средствами СП с одной стороны, реализовать все только средствами СУБД - с другой. Имхо, большая ошибка изначально делать ставку на такие ортодоксальные варианты. Гибче, гибче... и мягче.
...
Рейтинг: 0 / 0
01.02.2010, 23:23
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443310
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
skmdeveloperПО, какими бы замечательными характеристиками не обладало, но вокруг которого обязательно должны бегать с бубном SQL-гуру и еще толпа узких специалистов, обязательно будет занимать мизерную долю на рынке
нельзя сказать, что SQL является узкой специализацией. Даже, судя по этому форуму, русский язык является гораздо более специализированным знанием.
...
Рейтинг: 0 / 0
01.02.2010, 23:25
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443333
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
Егоров АлександрКакая такая поддержка? :) Сказано же - "новый контракт + новая разработка + новое внедрение" ;)
Вопросы про поддержку я задавал тут , тут и тут. Ответов пока нет :)вероятно вопросы ко мне

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

У нас конкретные решения, пока я не сталкивался с "Что происходит у Вас, когда одному клиенту внедрена система с аудитом, а другому - без?". Хотя у одного из заказчиков было подобное. Решено было интересно: было сделано ядро системы имеющее ВЕСЬ функционал. Дальше, в случае необходимости, через IoC любая логика перекрывалась кастомизацией. Хотя БЛ для некоторых заказчиков перепахивала пол-системы.
...
Рейтинг: 0 / 0
01.02.2010, 23:54
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443334
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
Егоров АлександрСобсно и вопросы про поддержку тогда снимаются - у Вас просто не может возникнуть ситуации, когда один проект разваливается на две ветки из-за прихоти клиентов :)Был такой проект - у него было 8+1 ветки: ядро (базовая БЛ) и 8 несвязанных кастомизаций (БЛ под конкретного заказчика / страну / законы).
...
Рейтинг: 0 / 0
01.02.2010, 23:57
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443338
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
Егоров АлександрПонимаю, что цифры эти не более чем "попугаи", но стоит подумать о разнице нагрузки на порядок и геометрическую зависимость от сложности БЛ. Кластер из "сотни Апп-серверов" нас, конечно, выручит. ;) Но ведь кластер - это не только серверное железо, это еще и внешние дисковые массивы, и сверхскоростные межсерверные коммуникации. А это тянет за собой грамотного админа, дорогостоящего помещения с вентиляцией и кондиционированием. Да и бесперебойное питание всему эту делу понадобится немаленкое...

И все потому, что разработчику невыгодно держать в штате БД-программиста?.. ;)я привел несколько другой пример возьмем к примеру ebay - вы думаете у них логика в СУБД живет? А почему?

А если вы будете проектировать систему типа ebay куда вы вынесите логику?

PS у нас в одном из проектов БД мелко нашинкована между Oracle-овыми инстансами. СУБД-хи уже затыкаются на записи. зареганых пользователей у системы вроде около 0,5 млн. И DBA у них пачка сидит и программеров целый штат.
...
Рейтинг: 0 / 0
02.02.2010, 00:03
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443344
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
Егоров АлександрМеняем документооборот на 1000 заявок по 50 строк:
Вариант1: 1000*(2+13*50)=652000 "запросов"
Вариант2: 1000*(1+50+6)=57000 "запросов"теперь прикинем что есть устройства генерирующие эти "запросы". Сама обработка запроса имеет нагрузку эм... 100 MHz и длительность 10 секунд, обращения каждые 30 секунд, CPU на СУБД - 2 000 MHz. Тогда какие то 60 устройств выведут СУБД из строя ибо CPU на управление данными уже не останется - все уйдет на обработку запросов клиентов.

Ставим 2 АппСервера той же мощности CPU и СУБД опять дышит свободно Причем мы имеем гарантию что не нужно апгрейдить железо если клиентов станет больше - будем докупать компьютеры и линейно масштабировать систему.

PS на указание про загрузку сети скажу, что и 1Gbit уже существует и распределенные кэши придуманы чтобы лишний раз СУБД не дергать когда ответ и так известен. Так что не все однозначно.
...
Рейтинг: 0 / 0
02.02.2010, 00:13
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443426
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
Bogdanov AndreyОстается только сравнить "пропускную способность" сети и сервера базы данных и понять в каком из двух вариантов мы раньше "упремся". Вряд ли ответ столь очевиден.А почему Вы считаете, что на SQL сервере будет выполняться "построчная" проверка? В выбранном примере проверка всех условий по всем строкам одного документа - это один "запрос". Выполненный приложением, которая оптимизирована на такие запросы. И почему Вы считаете, что "+еще некая математика" на сервере БД потребует бОльшей нагрузки, чем на сервере приложений?
Bogdanov AndreyУмные люди для разных задач используют разные инструменты. Для реализации бизнес-логики одни, для хранения данных - другие. И для каждой задачи стараются выбрать наиболее подходящий инструмент.Умные люди по-максимому используют возможности РСУБД. А не используют их только для хранения данных. Вопрос-то почему другие умные люди не используют по-максимому возможности ООБД? Или Вы считаете, что РСУБД - это самый подходящий инструмент для ОО-работы с данными? Или Вы считаете, что ООБД не лучший инструмент для ОО-работы с данными? Или Вы сомневаетесь, что РСУБД имеет какие-либо преимущества перед ООБД в умении хранить данные?
...
Рейтинг: 0 / 0
02.02.2010, 03:54
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443437
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
VoDAтеперь прикинем что есть устройства генерирующие эти "запросы". Сама обработка запроса имеет нагрузку эм... 100 MHz и длительность 10 секунд, обращения каждые 30 секунд, CPU на СУБД - 2 000 MHz. Тогда какие то 60 устройств выведут СУБД из строя ибо CPU на управление данными уже не останется - все уйдет на обработку запросов клиентов.
Я вроде нигде не говорил, что все нужно делать в БД. "Вся логика только в БД" это такая же крайность, как и "Вся логика только на СП" или "Вся логика только на клиенте". Я говорю лишь о том, что "бизнес-логика" имеет вполне разделяемые части. Одну из которых, "манипуляцию данными", лучше всего размещать в СУБД, которая для этого и предназначена.

И давайте посмотрим Ваш вариант: CPU на СУБД - 2000Mhz, CPU на СП - тоже 2000MHz. Обработка Клиент<->СП - 3 "запроса", обработка БД<->СП в первом варианте - 13 "запросов", во втором - 5 запросов. То есть использование варианта "обработка данных на СП" в два раза больше грузит и СУБД, и СП. СУБД имеет даже больший чем в два раза увеличенный поток "клиентских запросов" (ведь СП для СУБД тоже клиент), СП в два раза больше занят "отправкой запросов к БД и обработкой ответов"... И при усложнении "бизнес-логики" эти лишние "вопросы-ответы" растут геометрически, хотя могли бы расти арифметически...
...
Рейтинг: 0 / 0
02.02.2010, 04:49
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443438
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
VoDAPS у нас в одном из проектов БД мелко нашинкована между Oracle-овыми инстансами. СУБД-хи уже затыкаются на записи. зареганых пользователей у системы вроде около 0,5 млн. И DBA у них пачка сидит и программеров целый штат.
Я правильно выделил? ;) Помимо оплаты самого проекта, клиенту пришлось прикупить еще пачку DBА с программерами? Или они там были изначально? Если это ваш проект, значит именно так Вы и спроектировали. ;)
...
Рейтинг: 0 / 0
02.02.2010, 04:56
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443440
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
skmdeveloperЯ о реальной жизни а не о грибах. ПО, какими бы замечательными характеристиками не обладало, но вокруг которого обязательно должны бегать с бубном SQL-гуру и еще толпа узких специалистов, обязательно будет занимать мизерную долю на рынке
Вот странно, почему вокруг 1С "бегающие с бубном SQL-гуру и еще толпа узких специалистов" позволяют 1Су даже расширять свой рынок? :) Вы же вроде сами работаете с 1С? Когда столкнетесь с проблемами быстродействия и масштабируемости 1С, особенно после того, как владелец начнет задавать вопросы типа "как это опять сервер надо покупать??? в прошлом году только купили, тебе опять мало???" - сами быстро станете и "SQL-гуру", и "узким специалистом", и с бубном танцевать научитесь. :)
...
Рейтинг: 0 / 0
02.02.2010, 05:08
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443488
skmdeveloper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skmdeveloper
Участник
Наоборот, в случае реализации бизнес логики на клиенте мы разгружаем сервер и нового сервера ежегодно уже не нужно покупать. Нельзя делать предположения о причинах потери на основе эмпирических умозаключений. Зачастую потери в быстродействии в 1С по причине неэффективно написанного кода. Посмотрите исходный код 1С-вских конфигураций. Местами складывается впечатление, что там писали студенты-первокурсники.
Простой пример. Раньше в 1С Бухгалтерии 7.7 не было акта сверки с контрагентами. Я году так примерно в 2001 написал. Все довольны. Со временем акт сверки появился и в типовой конфигурации. У одних моих клиентов в довольно большой по нашим масштабам организации получалось, что акт сверки формируется непозволительно долго - до 10 минут. Я поставил свой, написанный давным давно отчет. Формируется меньше минуты.
Роб Пайк Роб Пайк (англ. Rob Pike) предложил следующие «правила» в качестве аксиом программирования.[1] Одновременно эти правила могут выражать точку зрения на философию UNIX:

* Правило 1: Вы не знаете, где программа начнёт тормозить. Узкие места возникают в неожиданных местах, поэтому не стройте догадки и изучайте скорость работы программы до тех пор, пока не удостоверитесь, что узкое место найдено.
* Правило 2: Измерение. Не оптимизируйте скорость до тех пор, пока её не измерите, и даже если вы проверили какую-то часть кода с узким местом, проверьте остальные.
* Правило 3: Изощрённые алгоритмы являются медленными, если n мало, а n обычно мало. В изощрённых алгоритмах присутствуют большие константы. До тех пор, пока вы не убедитесь, что n часто становится большим, избегайте изощрённости (даже если n становится большим, вначале используйте правило 2).
* Правило 4: Изощрённые алгоритмы чаще подвержены ошибкам, чем их простые аналоги, также их гораздо сложнее реализовать. Используйте простые алгоритмы наряду с использованием простых структур данных.
* Правило 5: Данные преобладают. При правильной и хорошо организованной структуре данных, алгоритмы становятся очевидными. Структуры данных, а не алгоритмы, являются центральной частью в программировании.
* Правило 6: Правила 6 нет.

http://ru.wikipedia.org/wiki/%D0%A4%D0%B8%D0%BB%D0%BE%D1%81%D0%BE%D1%84%D0%B8%D1%8F_UNIX]http://ru.wikipedia.org/wiki/Философия_UNIX]
...
Рейтинг: 0 / 0
02.02.2010, 07:30
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443605
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
Егоров АлександрVoDAPS у нас в одном из проектов БД мелко нашинкована между Oracle-овыми инстансами. СУБД-хи уже затыкаются на записи. зареганых пользователей у системы вроде около 0,5 млн. И DBA у них пачка сидит и программеров целый штат.
Я правильно выделил? ;) Помимо оплаты самого проекта, клиенту пришлось прикупить еще пачку DBА с программерами? Или они там были изначально? Если это ваш проект, значит именно так Вы и спроектировали. ;)выделили правильно я работаю в компании которая ко всему прочему аутсосер. Сколько в сумме компаний пилит ту систему и сколько ДБА сидит на подержке - ХЗ. По сути вся компания-заказчик это разработчики&DBA + разработчики&DBA от нас.
...
Рейтинг: 0 / 0
02.02.2010, 09:41
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443619
пролетевший
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
пролетевший
Участник
Егоров АлександрА почему Вы считаете, что на SQL сервере будет выполняться "построчная" проверка? В выбранном примере проверка всех условий по всем строкам одного документа - это один "запрос". Выполненный приложением, которая оптимизирована на такие запросы. И почему Вы считаете, что "+еще некая математика" на сервере БД потребует бОльшей нагрузки, чем на сервере приложений?
Одна строчка в описании запросов еще не значит одного запроса. И чтобы объяснить оптимизатору, как правильно построить план запроса все разработчики должны досконально разбираться с используемой СУБД ( а если их несколько ? ). Второй момент - и запросы, и логика выполняются на одной и той же системе. То есть как минимум ( считая что язык процедур СУБД как минимум столь же эффективен, как на сервере приложений ), требования к системе суммируются. Об этом ниже.
Егоров АлександрУмные люди по-максимому используют возможности РСУБД. А не используют их только для хранения данных.
Умным людям еще и деньги считать приходится. Поэтому кроме технических требований, к системе накладываются еще и финансовые. В приведенном вами примере, все рассчитано из предположения, что за каждой порцией данных сервер приложений лезет в базу. Но любой продавец сразу скажет - есть небольшое количество ходовых товаров, которые берут все, а экзотические заказы случаются достаточно редко. В плане приведенного примера это значит что информация о таких товаров попадает в кеш сервера, и количество запросов чтения будет на порядок а то и два меньше взятого "в лоб".
Сервера могут работать паралельно, обслуживая своих клиентов или свои кусочки пакетного задания. В результате, при логике на сервере - имеем несколько относительно дешевых машин, в противном случае - многопроцессорную суперсистему, или кластер из таких монстров, еще и требующий скоростной storage. Стоимость и железа, и лицензий во втором случае будет куда как выше... Ну и разрабатывать систему разделенную на относитьельно слабо связанные части, которые можно распределить между разными людьми и тестировать отдельно тоже дешевле.
...
Рейтинг: 0 / 0
02.02.2010, 09:48
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443727
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
когда о СУБД и бизнес-логике системы говорят как о "слабо связанных частях", возникает естественный вопрос: а о каких системах вообще речь идет, в которых логика слабо связана с данными. Похоже, что это интернет-проекты, в принципе имеющие косвенное отношение к бизнес-приложениям. Похоже просто сошлись разработчики интернет-порталов и разработчики учетных, производтсвенных и аналитических систем. Первым естественно не очень понятно, почему вторые так привязались к базе данных, что они там ценного нашли. Зато понятна причина java-мании. Так можно до бесконечности.
...
Рейтинг: 0 / 0
02.02.2010, 10:20
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443750
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
skmdeveloper,

Про типовые согласен. С другой стороны, Вы ведь скорее всего стоите больше студента-первокурсника? Значит в своем регионе Вы очень редкий 1С-гуру, если без Вас типовые конфигурации неприемлемо работают у некоторых клиентов? А что было бы с регионом, если бы Вас там не было? ;)

И почему Вы упорно считаете, что SQL-гуру это что-то из ряда вон выходящее? Освоить какой-либо диалект SQL намного проще, чем изучить устройство типовой 1С. Если Вы смогли самостоятельно разобраться с 1С, почему тогда считаете, что не сможете разобраться с SQL? У нас в регионе SQL-гуру появились как раз из-за обещаний 1С "на больших объемах данных используйте SQL и будет вам счастье". Когда растущие конторы стали спотыкаться о производительность, начали переводить свои 1Сы на SQL и столкнулись с тем, что такой перевод только ухудшает работу - многие 1С-гуру очень быстро превратились в SQL-гуру безо всяких особых напрягов. :)
...
Рейтинг: 0 / 0
02.02.2010, 10:30
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443876
baike2000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
baike2000
Участник
пролетевший
автор
Одна строчка в описании запросов еще не значит одного запроса. И чтобы объяснить оптимизатору, как правильно построить план запроса все разработчики должны досконально разбираться с используемой СУБД ( а если их несколько ? ).

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

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

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

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

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

автор Ну и разрабатывать систему разделенную на относитьельно слабо связанные части, которые можно распределить между разными людьми и тестировать отдельно тоже дешевле.
В этой части разработку бы уж не трогали. Это можно делать и при помещении БЛ в СУБД. Я вижу дополнительную сложность, только в том, что придется городить кучу ненужного кода в сервере АПП типа авторизации и проверки прав доступа.
...
Рейтинг: 0 / 0
02.02.2010, 11:09
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443912
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
пролетевший,

Кажется, опять пошло по кругу... Хорошо, попытаемся еще...

Почему в случае с СП Вы предполагаете эффективный кэш, а при работе СУБД нет?
Почему вы считаете, что в случае нескольких СП с одной СУБД кэш СП будет эффективен? Один клиент через первый СП выписал заявку на основании закешированных остатков и забрал весь товар, второй клиент через второй СП тоже выписал заявку на основании закэшированных остатков и тоже забрал весь товар. Быть того не может?
Менеджер с клиента через первый СП запретил скидки, но клиент через кэш второго СП этого не заметил и спокойно оформил заявку. Быть того не может?
Финансист придал клиенту статус "корпоративный". Закупщики этого клиента, выписывая каждый через свой СП, получили разные скидки на один и тот же товар, хотя их начальник клятверно заверил, что обо всем договорился. Просто потому, что одному из них повезло и он работал с кэшем того СП, через которого финансист и ставил этот статус. Опять быть того не может?

Или таки СП необходимо будет обращаться в базу на каждую заявку?
Или на СП нужно еще и прикрутить систему уведомления других СП об изменениях?

Как Вы считаете, как более эффективно потратит ресурсы РСУБД - на один запрос по четырем таблицам или на четыре запроса по одной таблице?

И опять таки? Где я хотя бы раз сказал, что вся бизнес-логика должна быть в БД? Ткните ссылкой, пожалуйста...
...
Рейтинг: 0 / 0
02.02.2010, 11:19
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36443918
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
baike2000,

1С, кстати, как раз и работает по принципу ORM. :) Боюсь только, что ORM у них тоже собственной разработки. :)
...
Рейтинг: 0 / 0
02.02.2010, 11:22
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36444296
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Егоров АлександрBogdanov AndreyОстается только сравнить "пропускную способность" сети и сервера базы данных и понять в каком из двух вариантов мы раньше "упремся". Вряд ли ответ столь очевиден.А почему Вы считаете, что на SQL сервере будет выполняться "построчная" проверка? В выбранном примере проверка всех условий по всем строкам одного документа - это один "запрос". Выполненный приложением, которая оптимизирована на такие запросы. И почему Вы считаете, что "+еще некая математика" на сервере БД потребует бОльшей нагрузки, чем на сервере приложений? Где вы увидели, что я что-то "считал". Какие-то цифры привели вы и на основании этих цифр хотели сделать какие-то выводы. Я просто указал, что ваши выводы гроша выеденного не стоят. Попытайтесь объяснить, что именно вы хотели своими цифрами показать. Где, на что и почему нагрузка выше.

Егоров АлександрBogdanov AndreyУмные люди для разных задач используют разные инструменты. Для реализации бизнес-логики одни, для хранения данных - другие. И для каждой задачи стараются выбрать наиболее подходящий инструмент.Умные люди по-максимому используют возможности РСУБД. А не используют их только для хранения данных. Вопрос-то почему другие умные люди не используют по-максимому возможности ООБД? Или Вы считаете, что РСУБД - это самый подходящий инструмент для ОО-работы с данными? Или Вы считаете, что ООБД не лучший инструмент для ОО-работы с данными? Или Вы сомневаетесь, что РСУБД имеет какие-либо преимущества перед ООБД в умении хранить данные?
Как много вопросов. Вы действительно на все эти вопросы хотите у меня ответы получить?
Давайте по-порядку:
1. Не могу сказать за всех умных людей, но некот орые используют возможности ООБД в тех задачах, гда считают это оправданным.
2. Я не очень понимаю что вы называете "ОО-работой с данными". Но подозреваю, что РСУБД для этой работы не лучший инструмент.
3. Опять же не знаю, что вы называете "ОО-работой", но и в данном случае считаю, что ООБД не лучший инсрумент для работы с данными. Это хороший инструмент для храненния "ОО-данных".
4. Нет не сомневаюсь. В умении хранить данные РСУБД имеет некоторые преимущества. Но какое это имеет отношение к бизнес-логике не знаю.
...
Рейтинг: 0 / 0
02.02.2010, 13:02
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36444712
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
Bogdanov AndreyПопытайтесь объяснить, что именно вы хотели своими цифрами показать. Где, на что и почему нагрузка выше.Все, что я хотел показать этими цифрами я показал. Считаю, что цифры хоть и "попугаи", но достаточного обоснованные. Вы приплюсовали к моим цифрам свои и сказали "ибо так!". Оснований Ваших цифр я вообще не видел.
Bogdanov Andrey1. Не могу сказать за всех умных людей, но некот орые используют возможности ООБД в тех задачах, гда считают это оправданным.Я это и не отрицал.
Bogdanov Andrey2. Я не очень понимаю что вы называете "ОО-работой с данными". Но подозреваю, что РСУБД для этой работы не лучший инструмент.Вы абсолютно правильно поняли, что я имел ввиду под "ОО-работой с данными". Я не знаю как правильно называется объектная обработка данных. ORM, Hibernate и прочее - это технологии, а как назвать сам принцип? :)
Bogdanov Andrey3. Опять же не знаю, что вы называете "ОО-работой", но и в данном случае считаю, что ООБД не лучший инсрумент для работы с данными. Это хороший инструмент для храненния "ОО-данных".
4. Нет не сомневаюсь. В умении хранить данные РСУБД имеет некоторые преимущества. Но какое это имеет отношение к бизнес-логике не знаю.
Я тоже не сомневаюсь в возможностях РСУБД. Я могу сказать только, что убежден в том , что при "ОО-работе с данными" с использованием ООБД не надо городить лишниюю прослойку ORMа, и можно использовать готовый объектно-ориентированный функционал СУБД. Это будет в любом случае эффективней, чем использование РСУБД (которая "не лучший инструмент") через дополнительнйю прослойку в виде ORMа. Поскольку мои убеждения расходятся с действительностью - я и пытаюсь узнать, по каким критериям для "ОО-работы с данными" выбирается не самые лучшие инструменты, требующие дополнительны прослоек, вместо выбора наиболее оптимальных (с моей точки зрения) инструментов. Объективных ответов я особо не вижу.
...
Рейтинг: 0 / 0
02.02.2010, 15:03
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36444940
CountZerro
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CountZerro
Гость
Внесу свои 3 коп. на правах сугубо IMHO

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

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

- На сервер выкладываем логику. связанную с поддержкой ограничений и целостности в самом широком смысле, поддержку избыточности (денормализации) + массовые сервисные операции (ФИФО/ЛИФО, переоценка/резервирование, начисление доходов по остаткам, вычисление средневзвешенных и среднепотолочных и т.д). Причем, на сервере более естественно мыслить не в терминах объектов, а в терминах чистых реляций (а по этому и язык более естественен PL/SQL или TSQL).

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

Разделение это конечно очень условно и субъективно.

Другая проблема - какие методы/процедуры давать пользователю настраивать под свои нужды, а какие нет. Меня всегда коробит, когда поддержка пользователя может свободно менять все что угодно на сервере, надежностью тут и не пахнет. А как искать ошибку в случае чего, как обновлять при обновлении версии, когда не знаешь, какие ограничения из заложенных разработчиком поддерживались, а какие нет. Но в то же время совсем не пускать пользователя на сервер то же жестоко - часто работать будет невозможно.
Опять же сугубо IMHO как иногда возможное решение. Нужно разделить всю логику (объекты, процедуры) на две зоны - доступные для изменения только разработчиками, и разрешенные для изменения подержкой пользователя (или даже на три - для разработчиков, для собственной службы внедрения, и для подержки пользователя).
Доступ с методам ядра ограничивается техническими и юридическими средствами (шифрование процедур, поставка только компилированного кода, ограничение прав, копирайт, отказ от обслуживания/исправления ошибок в случае нарушения и т.д. в меру испорченности фантазии), прочие процедуры поставляются в исходном коде и копирайт на них распространяется с изъятиями.
Но это IMHO перпендикулярная проблема к разделению по слоям - как ядерные так и пользовательские процедуры/объекты могут быть везде - на клиенте, в промслое, на сервере.


Но еще раз повторюсь - все это разделение - по возможности и необходимости. Вот занимаюсь проектом где все совсем не так как я написал выше.
...
Рейтинг: 0 / 0
02.02.2010, 16:13
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36445169
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Егоров АлександрВсе, что я хотел показать этими цифрами я показал. Считаю, что цифры хоть и "попугаи", но достаточного обоснованные.Обычно желая что-то показать показывают это не себе, а собеседнику. Мне осталось непонятно что вы хотели показать. Мне ваши попугаи ничего не показывают. Но если вы сам с собой беседуете, то я пройду мимо.

Егоров АлександрПоскольку мои убеждения расходятся с действительностью - я и пытаюсь узнать, по каким критериям для "ОО-работы с данными" выбирается не самые лучшие инструменты, требующие дополнительны прослоек, вместо выбора наиболее оптимальных (с моей точки зрения) инструментов. Объективных ответов я особо не вижу. Ну тут вы вообще что-то свое придумали и пытаетесь с этим спорить. Попробуйте прочитать, что другие пишут. Ваши оппоненты предлагали для "ОО-работы" использовать "объектные языки" (в частности Java и C# пробегали). Или вы считаете, что "объектные языки" не самые лучшие инструменты для "ОО-работы"? Назовите лучшие.
...
Рейтинг: 0 / 0
02.02.2010, 17:11
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36445220
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Bogdanov Andrey, "ОО-работы с данными ".
незначительное вроде сокращение цитаты, а смысл меняет кардинально. Не нужно (умышленно?)запутывать нить беседы.
...
Рейтинг: 0 / 0
02.02.2010, 17:23
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36445253
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
CountZerroКак один из красивых вариантов разделения логики на промежуточный и серверный слои (иногда - оптимальный, иногда - нет) я бы рассмотрел такой:

- На сервер выкладываем логику. связанную с поддержкой ограничений и целостности...
- В промежуточный слой выносим бизнес-логику в узком смысле...Именно. СУБД обеспечивает функционриование модели данных, а промежуточный слой - бизнес-логики. Где именно кончается модель данных и начинается бизнес-логика остается на усмотрение конкретного архитектора в конкретной задаче (хотя рекомендации общего характера и существуют). Можно только немного перефразировать iscrafm и отметить, что "чем гибче язык требуется для описания модели данных, тем более коряво она спроектирована". В подавляющем большинстве случаев для описания модели данных вполне достаточно чисто реляционных понятий и "голого SQL". А вот бизнес-логика более удобно формулируется в других терминах и использование ООП для ее выражения предпочтительнее.
...
Рейтинг: 0 / 0
02.02.2010, 17:32
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36445260
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
iscrafmBogdanov Andrey, "ОО-работы с данными ".
незначительное вроде сокращение цитаты, а смысл меняет кардинально. Не нужно (умышленно?)запутывать нить беседы.Я уже сказал, что не знаю, что означает этот термин, а посему "аккуратно" относиться к нему не могу.
...
Рейтинг: 0 / 0
02.02.2010, 17:33
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36445291
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Bogdanov AndreyiscrafmBogdanov Andrey, "ОО-работы с данными ".
незначительное вроде сокращение цитаты, а смысл меняет кардинально. Не нужно (умышленно?)запутывать нить беседы.Я уже сказал, что не знаю, что означает этот термин, а посему "аккуратно" относиться к нему не могу.
зачем коментировать то, что не знаешь... Можно оставить без внимания непонятные вопросы. Имхо конечно. Речь идет о том, что данные реляционные, а их обработка манипулирует объектами. Между ними - "прокладка" в виде ORM
...
Рейтинг: 0 / 0
02.02.2010, 17:40
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36445321
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Bogdanov Andreyбизнес-логика более удобно формулируется в других терминах и использование ООП для ее выражения предпочтительнее.
по своей сути, бизнес-логика более естественно описывается и представляется декларациями или функциями. Ну уж никак не объектами. Как и случае с ORM, под объекты она "подгоняется", т.е. функции бизнес-логики транслируются в методы объектов и т.п., образно.
...
Рейтинг: 0 / 0
02.02.2010, 17:47
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36445343
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
Bogdanov AndreyМне ваши попугаи ничего не показывают. Но если вы сам с собой беседуете, то я пройду мимо.Ну, не убедил, так не убедил. :) Собеседник, которому были адресованы эти цифры, уже объснил, что правило "все делается только на СП" финансовое, а не технические решение. Мне этого объяснения достаточно. :)
Bogdanov AndreyВаши оппоненты предлагали для "ОО-работы" использовать "объектные языки" (в частности Java и C# пробегали). Или вы считаете, что "объектные языки" не самые лучшие инструменты для "ОО-работы"? Назовите лучшие.
Причем тут языки-то? Я больше про работу с БД спрашивал. Хорошо, спрошу по другому.

Почему чаще всего для "ОО-работы с данными" используется связка "Java -> ORM -> Провайдер -> РСУБД", а не связка "Java -> Провайдер -> ООБД", если известно, что "РСУБД для этой работы не лучший инструмент."?
...
Рейтинг: 0 / 0
02.02.2010, 17:51
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36445424
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
iscrafmРечь идет о том, что данные реляционные, а их обработка манипулирует объектами. Между ними - "прокладка" в виде ORM
Iscrafm, имеено об этом речь и идет. Спасибо за понимание! :)

Добавлю: ...при этом утверждается, что это самая эффективная архитектура, для разработки бизнес-приложений. Хотя форум вроде и технический, но все объяснения сводятся к тому, что "так мне, как разработчику дешевле", "потому что БД рухнет от клиентских запросов", ну и козырное "верую, ибо свято!" :)
...
Рейтинг: 0 / 0
02.02.2010, 18:09
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36445460
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Егоров АлександрПочему чаще всего для "ОО-работы с данными" используется связка "Java -> ORM -> Провайдер -> РСУБД", а не связка "Java -> Провайдер -> ООБД", если известно, что "РСУБД для этой работы не лучший инструмент."?А вы попробуйте мухи от котлет отделить. Нет никакой "ОО-работы с данными". Есть данные, есть алгоритмы. Данные наиболее удобно описываются реляционной моделью (большинству людей, видимо, проще понимать описание данных в виде "таблиц"). А вот алгоритмы в реляционной модели отсутствуют. И для описания алгоритмов ОО-подход более удобен и нагляден. Ортодоксы могут применять один и тот же инструмент во всех случаях жизни. Но это ближе к религиозному фанатизму. А большинство использует то, что удобнее и понятнее для конкретной задачи.
...
Рейтинг: 0 / 0
02.02.2010, 18:21
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36445537
CountZerro
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CountZerro
Гость
iscrafmBogdanov Andreyбизнес-логика более удобно формулируется в других терминах и использование ООП для ее выражения предпочтительнее.
по своей сути, бизнес-логика более естественно описывается и представляется декларациями или функциями. Ну уж никак не объектами. Как и случае с ORM, под объекты она "подгоняется", т.е. функции бизнес-логики транслируются в методы объектов и т.п., образно.

А вот никак не могу согласиться!
Тупой и корявый пример, просто для иллюстрации:
Берем Счет
Проверяем оплату
По счету формируем накладную
По накладной оформляем отгрузку, в частности - формируем счет-фактуру
и т.д.
Чистые объекты и действия над ними, и не надо задумываться об их внутренней структуре и прочих деталях. Все документы - наследники абстрактного класса "Документ", имеют общие методы (регистрируются в журнале входящих/исходящих, посылаются по почте, печатаются и проч.)
Очень естественно и описывается на русском языке, и напрямую транслируется в объекты и методы.

А вот при составлении отчетности проще мыслить в терминах сущностей реляционной модели, объекты только мешаются (извлечь количество и сумму продаж из накладных по 5 товарам с максимальными объемами продаж - зачем тут объекты?)

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

Никакой религии, я так вижу (с)! Объектно-реляционный дуализьм, природу мать вашу не обманешь:))
...
Рейтинг: 0 / 0
02.02.2010, 18:59
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36445550
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
Егоров АлександрПочему чаще всего для "ОО-работы с данными" используется связка "Java -> ORM -> Провайдер -> РСУБД", если известно, что "РСУБД для этой работы не лучший инструмент."?
Bogdanov Andreyбольшинство использует то, что удобнее и понятнее для конкретной задачи.
Вы только потверждаете мое мнение, что эффективность полученного решения - не самая главная цель таких разработчиков.
...
Рейтинг: 0 / 0
02.02.2010, 19:07
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36445605
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Егоров АлександрВы только потверждаете мое мнение, что эффективность полученного решения - не самая главная цель таких разработчиков.Все сильно зависит от тог, что понимать под "эффективностью". Если измерять количество строк кода, то получим одно, если скорость разработки, то другое, если скорость работы приложения то третье и т.д.
Для бизнеса эффективность определяется количеством средств потребных для достижения задачи. И с этой точки зрения наиболее удобные средства чаще всего более эффективны.
...
Рейтинг: 0 / 0
02.02.2010, 19:39
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36445665
Не Hibernate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Не Hibernate
Гость
Егоров АлександрЕгоров АлександрПочему чаще всего для "ОО-работы с данными" используется связка "Java -> ORM -> Провайдер -> РСУБД", если известно, что "РСУБД для этой работы не лучший инструмент."?
Bogdanov Andreyбольшинство использует то, что удобнее и понятнее для конкретной задачи.
Вы только потверждаете мое мнение, что эффективность полученного решения - не самая главная цель таких разработчиков.

Странно, но под ООП здесь понимают только Hibernate и ORM. Hibernate - редкий уродец, который, действительно, производительностью и удобством не блещет, но есть и другие варианты. В них бизнес-объекты не зависят от структуры БД и DAL(можно использовать и хранимые процедуры), это позволяет сочетать достоинства двух крайних,горячо здесь обсуждаемых, вариантов.
...
Рейтинг: 0 / 0
02.02.2010, 20:26
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36446014
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
вообще, бизнес-логика должна находиться в ОО-модели а не в ХП хотя-бы потому, что при реализации ее в ХП получается функциональная декомпозиция системы, которая менее устойчива к изменениям, чем обьектная, это обьясняется тем, что при развитии системы чаще меняются именно функции обработки данных, чем сами данные (т.е. обьекты). К другим достоинствам относится то, что нормальную доменную модель легче сопровождать и понимать, чем ворох функций.

Маппинг обьектов на таблицы желательно делать не на сами таблицы, а на ХП-обертки сущностей, таким образом мы выстраиваем своеобразный интерфейс к БД к которому обращаются клиенты. Такая изоляция (помимо безопасности) позволяет производить рефакторинг БД не трогая клиента

Конечно всю БЛ в доменную модель запихнуть получается не всегда, некоторые функции просто тупо более эффективны на sql, и если это становится критичным, то они просто переносятся в ХП, но трактуются именно как оптимизационные решения, а не архитектурные
...
Рейтинг: 0 / 0
03.02.2010, 01:54
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36446026
Не ORM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Не ORM
Гость
StalkerSвообще, бизнес-логика должна находиться в ОО-модели а не в ХП хотя-бы потому, что при реализации ее в ХП получается функциональная декомпозиция системы, которая менее устойчива к изменениям, чем обьектная, это обьясняется тем, что при развитии системы чаще меняются именно функции обработки данных, чем сами данные (т.е. обьекты). К другим достоинствам относится то, что нормальную доменную модель легче сопровождать и понимать, чем ворох функций.

Маппинг обьектов на таблицы желательно делать не на сами таблицы, а на ХП-обертки сущностей, таким образом мы выстраиваем своеобразный интерфейс к БД к которому обращаются клиенты. Такая изоляция (помимо безопасности) позволяет производить рефакторинг БД не трогая клиента

Конечно всю БЛ в доменную модель запихнуть получается не всегда, некоторые функции просто тупо более эффективны на sql, и если это становится критичным, то они просто переносятся в ХП, но трактуются именно как оптимизационные решения, а не архитектурные

Типичные рассуждения разработчика клиентской части с перетягиванием одеяла на себя.
Пухлые клиенты с анемичной БД. Такая телега с люфтом в одну сторону только норовит съехать в обочину.
...
Рейтинг: 0 / 0
03.02.2010, 02:36
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36446066
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
Bogdanov AndreyДля бизнеса эффективность определяется количеством средств потребных для достижения задачи. И с этой точки зрения наиболее удобные средства чаще всего более эффективны.
Согласен, Просто зачастую у бизнеса-потребителя ПО несколько другие понятия эффективности, чем у бизнеса-разработчика ПО. Более удобное и простое ПО для потребителя может обернуться весьма значимыми затратами на его поддержку, о которых разработчик ПО при продаже\внедрении скромно умалчивает. :)
...
Рейтинг: 0 / 0
03.02.2010, 06:14
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36446071
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
Не Hibernateесть и другие варианты. В них бизнес-объекты не зависят от структуры БД и DAL(можно использовать и хранимые процедуры), это позволяет сочетать достоинства двух крайних,горячо здесь обсуждаемых, вариантов.
Именно такой вариант и предлагается. Просто его почему-то упорно называют "вся бизнес-логика в СУБД". :)
...
Рейтинг: 0 / 0
03.02.2010, 06:29
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36446168
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
CountZerroiscrafmBogdanov Andreyбизнес-логика более удобно формулируется в других терминах и использование ООП для ее выражения предпочтительнее.
по своей сути, бизнес-логика более естественно описывается и представляется декларациями или функциями. Ну уж никак не объектами. Как и случае с ORM, под объекты она "подгоняется", т.е. функции бизнес-логики транслируются в методы объектов и т.п., образно.

А вот никак не могу согласиться!
Тупой и корявый пример, просто для иллюстрации:
Берем Счет
Проверяем оплату
По счету формируем накладную
По накладной оформляем отгрузку, в частности - формируем счет-фактуру
и т.д.
Чистые объекты и действия над ними, и не надо задумываться об их внутренней структуре и прочих деталях. Все документы - наследники абстрактного класса "Документ", имеют общие методы (регистрируются в журнале входящих/исходящих, посылаются по почте, печатаются и проч.)
Очень естественно и описывается на русском языке, и напрямую транслируется в объекты и методы.

Пример как раз хорошо описывает взаимодействие сервисов (функций) бизнес-логики. Ваша трансляция в объекты и методы, это уже трансляция , не забывайте об этом. Придумали абстрактный класс, нафантазировали ему методов и т.д. и т.п.
...
Рейтинг: 0 / 0
03.02.2010, 09:01
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36446229
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
из своего опыта: разрабатывали в банке информ систему онлайн сбора и учета информации
так как еще были уже чуть-чуть не студентами - кинулись делать все ао науке - 3 звена:
-морда (в ней часть бизнес логики по манипуляции данными и биению по рукам юзера)
-среднее звено(укрупненная логика типа оплатить, переслать, проверить и т.д. и т.п.)
-БД(проверка целостности и ограничения)

заманались все это поддерживать и обновлять!
когда становишся старее - стараешся все делать с минимумом телодвижений - т.е оптимальней! ))))

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

в итоге теперь у нас меньше геммороя ровно на 1 звено - среднее - потому как при любом чихе править 3 звена - извините это только для студентам может позазаться нормальной практикой )
...
Рейтинг: 0 / 0
03.02.2010, 09:48
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36446268
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Егоров АлександрСогласен, Просто зачастую у бизнеса-потребителя ПО несколько другие понятия эффективности, чем у бизнеса-разработчика ПО. Более удобное и простое ПО для потребителя может обернуться весьма значимыми затратами на его поддержку, о которых разработчик ПО при продаже\внедрении скромно умалчивает. :)
Вы хотите сказать, что ОО-системы более затратны в поддержке? Можете привести статистику, или какие-то разумные доводы кроме своего имхо?
Основная доля затрат на поддержку - это стоимость модификаций и модернизаций. ОО-подход более адаптивен и гораздо лучше переваривает изменения. Несомненно наличие грамотного архитектора и централизация всех изменений сильно упрощают модификацию и для не ОО-систем. Но как раз потребитель не имеет грамотных архитекторов, а желает выполнять некторые модификации своими руами (так как чужие слишком дороги).
...
Рейтинг: 0 / 0
03.02.2010, 10:06
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36446287
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
Мне не ясно, почему использование сервера приложений позволит расположить БЛ в одном месте?

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

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

Разнесение БЛ на несколько серверов приложений одномоментно развеивает миф о едином месте хранения оной : функции разных приложений так или иначе пересекаются и сервера приложений будут поневоле их дублировать.
Выделить еще один сервер приложений для "общей функциональности"?
А не выйдет, т.к. области пересечений интересов разных приложений тоже различны.
...
Рейтинг: 0 / 0
03.02.2010, 10:15
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36446373
Не Hibernate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Не Hibernate
Гость
Егоров АлександрНе Hibernateесть и другие варианты. В них бизнес-объекты не зависят от структуры БД и DAL(можно использовать и хранимые процедуры), это позволяет сочетать достоинства двух крайних,горячо здесь обсуждаемых, вариантов.
Именно такой вариант и предлагается. Просто его почему-то упорно называют "вся бизнес-логика в СУБД". :)

Нет. Это другой крайний вариант с другим люфтом. Взять хотя бы проверку на constraine c выводом вменяемых сообщений пользователю.
...
Рейтинг: 0 / 0
03.02.2010, 10:47
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36446411
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
Bogdanov AndreyВы хотите сказать, что ОО-системы более затратны в поддержке? Можете привести статистику, или какие-то разумные доводы кроме своего имхо?
Основная доля затрат на поддержку - это стоимость модификаций и модернизаций. ОО-подход более адаптивен и гораздо лучше переваривает изменения. Несомненно наличие грамотного архитектора и централизация всех изменений сильно упрощают модификацию и для не ОО-систем. Но как раз потребитель не имеет грамотных архитекторов, а желает выполнять некторые модификации своими руами (так как чужие слишком дороги).
Вобщем-то я имел ввиду только системы, у которых вся бизнес-логика написана на объектно-ориентированном ЯВУ и работает с РСУБД через ORM не используя возможности этих СУБД по обработке данных. Статистику привести не могу. Но мо мнение авторы подобных ОО-систем поколебать не смогли. :) На пример необходимых изменений в "разделенной" системе, получен пример необходимых изменений в ОО-ситеме. Это совпадает с моим мнением. Ибо более затратные телодвижения разработчика по модификации бизнес-логики естественно будут переложены на кошелек заказчика. :) Обратных примеров приведено не было ни одного. Спорным вопросом остается также совокупная стоимость железа, требуемая для работы разных систем. Включая затраты на его содержание, естественно.

Боюсь, что мы действительно пытаемся спорить о совершенно разных системах. Вернее, как заметил Iscrafm, о системах совершенно различного применения.
...
Рейтинг: 0 / 0
03.02.2010, 11:00
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36446427
Не Hibernate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Не Hibernate
Гость
Егоров АлександрНе Hibernateесть и другие варианты. В них бизнес-объекты не зависят от структуры БД и DAL(можно использовать и хранимые процедуры), это позволяет сочетать достоинства двух крайних,горячо здесь обсуждаемых, вариантов.
Именно такой вариант и предлагается. Просто его почему-то упорно называют "вся бизнес-логика в СУБД". :)
Помимо ORM есть вариации на тему Active Record. В них БО не зависит от структуры БД, полностью скрыта работа с ней, предоставляются только нужные интерфейсы. Нет танцев с бубнами для маппинга ORM, можно работать с процедурами, распределить БЛ по двум слоям.
Совсем другой вариант . Еще один экстремист, ему даже мало одной БД.
Вариантов много.
...
Рейтинг: 0 / 0
03.02.2010, 11:03
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36446477
Не Hibernate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Не Hibernate
Гость
Егоров АлександрBogdanov AndreyВы хотите сказать, что ОО-системы более затратны в поддержке? Можете привести статистику, или какие-то разумные доводы кроме своего имхо?
Основная доля затрат на поддержку - это стоимость модификаций и модернизаций. ОО-подход более адаптивен и гораздо лучше переваривает изменения. Несомненно наличие грамотного архитектора и централизация всех изменений сильно упрощают модификацию и для не ОО-систем. Но как раз потребитель не имеет грамотных архитекторов, а желает выполнять некторые модификации своими руами (так как чужие слишком дороги).
Вобщем-то я имел ввиду только системы, у которых вся бизнес-логика написана на объектно-ориентированном ЯВУ и работает с РСУБД через ORM не используя возможности этих СУБД по обработке данных. Статистику привести не могу. Но мо мнение авторы подобных ОО-систем поколебать не смогли. :) На пример необходимых изменений в "разделенной" системе, получен пример необходимых изменений в ОО-ситеме. Это совпадает с моим мнением. Ибо более затратные телодвижения разработчика по модификации бизнес-логики естественно будут переложены на кошелек заказчика. :) Обратных примеров приведено не было ни одного. Спорным вопросом остается также совокупная стоимость железа, требуемая для работы разных систем. Включая затраты на его содержание, естественно.

Боюсь, что мы действительно пытаемся спорить о совершенно разных системах. Вернее, как заметил Iscrafm, о системах совершенно различного применения.
Правильно, системы бывают разные. Валидация данных в удаленной БД совершенно неприемлема(лишний трафик и существенные задержки). Подсчет в примере совершенно не учитывает варианты, когда после проверок БД говорит - не шмогла. Помимо этого, за счет кеширования ООП можно убрать некоторые шаги и обращения к БД.
...
Рейтинг: 0 / 0
03.02.2010, 11:19
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36446622
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
Не HibernateЕгоров АлександрНе Hibernateесть и другие варианты. В них бизнес-объекты не зависят от структуры БД и DAL(можно использовать и хранимые процедуры), это позволяет сочетать достоинства двух крайних,горячо здесь обсуждаемых, вариантов.
Именно такой вариант и предлагается. Просто его почему-то упорно называют "вся бизнес-логика в СУБД". :)Нет. Это другой крайний вариант с другим люфтом. Взять хотя бы проверку на constraine c выводом вменяемых сообщений пользователю.Речь не о "проверке констрейтов", а о выполнении бизнес-функции "проверка правильности заявки" и "обработка приема заявки". Часть БЛ, размещенная, например, на СП - говорит о том, что Заявка моджет принять статус "принята" только после валидации. Метод валидации заявки вызывается там же. Код этого метода - может быть вызовом ХП, а может и не быть. Вывод результатов валидации пользователю - стандартен и выполняется тоже на СП. Метод приема заявки - тоже самое. Он может состоять из отправки содержимого заявки на e-mail вообще без обращения к БД. Или после обработки Заявки в БД дергать какой-нить внешний веб-сервис. Все зависит от выбранного обработчика[-ов]. Пример был приведен с использованием проверки и принятия Заявки средствами БД как раз чтобы показать преимущество разнесения бизнес-логики на несколько слоев.
...
Рейтинг: 0 / 0
03.02.2010, 12:04
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36446833
Не Hibarnate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Не Hibarnate
Гость
Егоров АлександрНе HibernateЕгоров АлександрНе Hibernateесть и другие варианты. В них бизнес-объекты не зависят от структуры БД и DAL(можно использовать и хранимые процедуры), это позволяет сочетать достоинства двух крайних,горячо здесь обсуждаемых, вариантов.
Именно такой вариант и предлагается. Просто его почему-то упорно называют "вся бизнес-логика в СУБД". :)Нет. Это другой крайний вариант с другим люфтом. Взять хотя бы проверку на constraine c выводом вменяемых сообщений пользователю.Речь не о "проверке констрейтов", а о выполнении бизнес-функции "проверка правильности заявки" и "обработка приема заявки". Часть БЛ, размещенная, например, на СП - говорит о том, что Заявка моджет принять статус "принята" только после валидации. Метод валидации заявки вызывается там же. Код этого метода - может быть вызовом ХП, а может и не быть. Вывод результатов валидации пользователю - стандартен и выполняется тоже на СП. Метод приема заявки - тоже самое. Он может состоять из отправки содержимого заявки на e-mail вообще без обращения к БД. Или после обработки Заявки в БД дергать какой-нить внешний веб-сервис. Все зависит от выбранного обработчика[-ов]. Пример был приведен с использованием проверки и принятия Заявки средствами БД как раз чтобы показать преимущество разнесения бизнес-логики на несколько слоев.
На мой скромный взгляд, пример для показа преимуществ выноса БЛ в БД выбран весьма неудачно.
Валидацию,подсчет агрегатов, проще и удобней делать в ООП, не говоря уже о том, что процесс приема заявки может быть достаточно сложным. Добавьте хотя бы простую проверку на дубликаты в деталировке, рассмотрите крайние случаи, цифры будут не в пользу БД.
...
Рейтинг: 0 / 0
03.02.2010, 12:58
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36446870
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Егоров АлександрВобщем-то я имел ввиду только системы, у которых вся бизнес-логика написана на объектно-ориентированном ЯВУ и работает с РСУБД через ORM не используя возможности этих СУБД по обработке данных.МЫ вроде бы не недостатки каких-то конкретных систем здесь обсуждаем, а некотрые общие архитектурные принципы. Можно найти огромное количество плохих систем построенных на любом архитектурном принципе. Но само наличие таких систем не доказывает, что принципы плохи. Тут надо либо статистикой оперировать, либо логические доказательства приводить.
...
Рейтинг: 0 / 0
03.02.2010, 13:09
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36446983
Не Hibernate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Не Hibernate
Гость
Bogdanov AndreyЕгоров АлександрВобщем-то я имел ввиду только системы, у которых вся бизнес-логика написана на объектно-ориентированном ЯВУ и работает с РСУБД через ORM не используя возможности этих СУБД по обработке данных.МЫ вроде бы не недостатки каких-то конкретных систем здесь обсуждаем, а некотрые общие архитектурные принципы. Можно найти огромное количество плохих систем построенных на любом архитектурном принципе. Но само наличие таких систем не доказывает, что принципы плохи. Тут надо либо статистикой оперировать, либо логические доказательства приводить.
За доказательствами далеко ходить не нужно. Достаточно рассмотреть для сравнения не идеальный вариант, а с ошибками ввода, которые могут повторяться. Учесть валидацию, контроль на дубликаты и добавить необходимость подсчета итоговой суммы хотя бы для 10 строк. Все это проще, быстрее, внятней для пользователя, лучше делать на клиенте с меньшей нагрузкой на БД.
...
Рейтинг: 0 / 0
03.02.2010, 13:38
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36447049
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
Не Hibarnateа мой скромный взгляд, пример для показа преимуществ выноса БЛ в БД выбран весьма неудачно. Валидацию,подсчет агрегатов, проще и удобней делать в ООП, не говоря уже о том, что процесс приема заявки может быть достаточно сложным. Добавьте хотя бы простую проверку на дубликаты в деталировке, рассмотрите крайние случаи, цифры будут не в пользу БД.Ну, не знаю. По условию задачи данные для проверки все были в БД, поэтому и проверку проще было сделать в БД. Проверка состояла бы из единственно запроса. Дубликаты и агрегаты я бы тоже делал не в БД, а в форме ввода.
...
Рейтинг: 0 / 0
03.02.2010, 13:53
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36447075
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Егоров АлександрПроверка состояла бы из единственно запроса. Если для реализации проверки в БД достаточно одно запроса, то почему в считаете, что для реализации той же проверки в среднем слое запросов потребуется больше? В крайнем случае можно "тупо" текст хранимой процедуры переписать на язык СП и количество запросов будет ровно тем же.
...
Рейтинг: 0 / 0
03.02.2010, 13:59
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36447077
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
Bogdanov Andrey,

Статистики или логических доказательств преимуществ архитектуры "все только на сп и только на ЯВУ" что-то вообще не видно...
...
Рейтинг: 0 / 0
03.02.2010, 14:00
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36447112
Не Hibernate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Не Hibernate
Гость
Егоров АлександрНе Hibarnateа мой скромный взгляд, пример для показа преимуществ выноса БЛ в БД выбран весьма неудачно. Валидацию,подсчет агрегатов, проще и удобней делать в ООП, не говоря уже о том, что процесс приема заявки может быть достаточно сложным. Добавьте хотя бы простую проверку на дубликаты в деталировке, рассмотрите крайние случаи, цифры будут не в пользу БД.Ну, не знаю. По условию задачи данные для проверки все были в БД, поэтому и проверку проще было сделать в БД. Проверка состояла бы из единственно запроса. Дубликаты и агрегаты я бы тоже делал не в БД, а в форме ввода.
Если даже запрос на валидацию единственный, он достаточно мутный, если выводить подробную информацию для пользователя. Вместо моментального показа неверно введенного значения с пояснением, выводим кашу со списком ошибок, пользователю нужно запомнить все, найти нужное место, исправить, еще раз подтвердить ввод. Позиций может быть много, процесс растянется до бесконечности.
...
Рейтинг: 0 / 0
03.02.2010, 14:11
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36447118
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Егоров АлександрСтатистики или логических доказательств преимуществ архитектуры "все только на сп и только на ЯВУ" что-то вообще не видно...Во-первых, если вы со мной оппонируете, то покажте, где я предлагал "все только на сп и ЯВУ". Во-вторых, задумайтесь (или погуглите) о том почему объектное программирование вытесняет процедурное. Ну и в-третьих, постарайтесь все-таки сформилировать какую архитектуру в рамках данного обсуждения вы поддерживаете.
...
Рейтинг: 0 / 0
03.02.2010, 14:13
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36447120
Не 1С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Не 1С
Гость
Егоров АлександрBogdanov Andrey,

Статистики или логических доказательств преимуществ архитектуры "все только на сп и только на ЯВУ" что-то вообще не видно...
Почему не видно? Можно посмотреть статистику и стоны относительно 1С.
...
Рейтинг: 0 / 0
03.02.2010, 14:13
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36447589
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
Bogdanov AndreyЕгоров АлександрСтатистики или логических доказательств преимуществ архитектуры "все только на сп и только на ЯВУ" что-то вообще не видно...Во-первых, если вы со мной оппонируете, то покажте, где я предлагал "все только на сп и ЯВУ". Во-вторых, задумайтесь (или погуглите) о том почему объектное программирование вытесняет процедурное. Ну и в-третьих, постарайтесь все-таки сформилировать какую архитектуру в рамках данного обсуждения вы поддерживаете.
1. Вот тут я почему-то пришел к такой мысли. Если не прав - извините.
2. Я не сомневаюсь в преимуществах объектно-ориентированного программирования перед процедурным. Я сомневаюсь в преимуществе объектно-ориентированной работы с данными в РСУБД используя технологиина базе ORM.
3. Я поддерживаю "многослойную" архитектуру для бизнес-приложений. С уклоном в сторону "манипуляцией данными лучше всего на уровне СУБД".
...
Рейтинг: 0 / 0
03.02.2010, 16:40
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36449145
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Егоров АлександрЯ сомневаюсь в преимуществе объектно-ориентированной работы с данными в РСУБД используя технологиина базе ORM.Я опять вас не понимаю. Что значит "объектно-ориентированная работа с данными"? Вообще, что вы называете "работой с данными". У меня ни в одной системе задачи "работы с данными" не возникало. Возникали задачи реализации того или иного бизнес-процесса или "user-case". Иногда от аналитиков исходят некоторые требования к структуре данных (хотя чаще структура появляется уже в процессе разбора требований по бизнес-процессам), но никаких требований к "работе с данными" я не видел. И по-моему опыту, реализация бизнес-процессов на ОО-языках происходит эффективнее (по скорости реализации и по простоте внесения изменений).
...
Рейтинг: 0 / 0
04.02.2010, 12:04
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36449279
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Bogdanov AndreyИ по-моему опыту, реализация бизнес-процессов на ОО-языках происходит эффективнее (по скорости реализации и по простоте внесения изменений).
с чем сравнивали? По моим исследованиям, подтвержденным конкретным проектами, скорость реализации, простота сопровождения и внесения изменений в системы поддержки бизнес-процессов в SOA архитектуре просто на порядки превосходит OO-программирование этих же БП. Как может императивное программирование, пусть даже завернутое в ОО фантик, быть быстрее и проще декларативного - загадка. Задайте себе этот вопрос и тоже попытайтесь на него ответить.
...
Рейтинг: 0 / 0
04.02.2010, 12:40
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36449797
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
iscrafmКак может императивное программирование, пусть даже завернутое в ОО фантик, быть быстрее и проще декларативного - загадка. Задайте себе этот вопрос и тоже попытайтесь на него ответить.Все встречавшиеся мне системы декларативного описания бизнес-логики на порядок сложнее для моего восприятия, чем императивное программирование. И соответственно требуют гораздо большего времени при попытке что-либо реализовать. Наверное мне попадались плохие системы. Даже чрезвычайно простой и понятный SQL большинству программистов дается гораздо хуже, чем С или Pascal.
...
Рейтинг: 0 / 0
04.02.2010, 15:01
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36449821
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
iscrafm,

Ну где же Ваша картинка с декларативным описанием условий?... ну помню, что Вы где-то на форуме показывали пример... вот только хоть убей, не могу вспомнить даже тему... тоже что-то было на тему "декларативное vs императивное"... :)
...
Рейтинг: 0 / 0
04.02.2010, 15:08
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36450188
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Егоров Александр,
постараюсь найти, просто сейчас в поездке, рабочего ноутбука нет с собой. Уже самому интересно, какую картинку Вы имеете ввиду.
...
Рейтинг: 0 / 0
04.02.2010, 16:50
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36450190
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Bogdanov AndreyiscrafmКак может императивное программирование, пусть даже завернутое в ОО фантик, быть быстрее и проще декларативного - загадка. Задайте себе этот вопрос и тоже попытайтесь на него ответить.Все встречавшиеся мне системы декларативного описания бизнес-логики на порядок сложнее для моего восприятия, чем императивное программирование. И соответственно требуют гораздо большего времени при попытке что-либо реализовать. Наверное мне попадались плохие системы. Даже чрезвычайно простой и понятный SQL большинству программистов дается гораздо хуже, чем С или Pascal.
понятно. спасибо за разъяснение.
...
Рейтинг: 0 / 0
04.02.2010, 16:52
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36450377
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
iscrafm,

нашел только Ваш конструктор проводок. А была еще картинка, где "внутренности" бизнес-функции описывалась exel-подобными формулами и скармливалась сервису на исполнение. Что-то типа:

Код: plaintext
1.
2.
Если Товар.Стоимость <100
И Товар.ДатаВвода < 31.12.2009
И РазрешеноМенеджером(Товар)=1...
...
Рейтинг: 0 / 0
04.02.2010, 17:48
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36450423
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
Bogdanov AndreyЕгоров АлександрЯ сомневаюсь в преимуществе объектно-ориентированной работы с данными в РСУБД используя технологии на базе ORM .Я опять вас не понимаю...Выделил непонятное...
Bogdanov AndreyВообще, что вы называете "работой с данными". У меня ни в одной системе задачи "работы с данными" не возникало. Возникали задачи реализации того или иного бизнес-процесса или "user-case". А что тогда делает Ваша система, например, при обработке бизнес-процесса "принять заявку к исполнению" (внутри которого есть бизнес-функция "зарезервировать товар по заявке"), чтобы результат этого процесса отразился у других пользователей системы?
...
Рейтинг: 0 / 0
04.02.2010, 18:07
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36451161
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Егоров АлександрА что тогда делает Ваша система, например, при обработке бизнес-процесса "принять заявку к исполнению" (внутри которого есть бизнес-функция "зарезервировать товар по заявке"), чтобы результат этого процесса отразился у других пользователей системы?Для разработчика бизнес-функций это выглядит, как "Товар.Зарезервировать(количество)". И проблем с пониманием того, что эта запись означает ни у кого не возникает. А учитывая, что среда еще и сама список доступных методов показывает, то и проблем с написанием тоже. И этот разработчик не задумывается о том, что такое "Товар" - просто идентификатор или какая-то сложная структура, о том что делает метод "Зарезервировать" - просто update, или вызывает Web-сервис и рассылает десяток писем и СМС с предупреждениями
Я утрирую, конечно, но метод "резервировать товар по заявке" я писал несколько лет назад и всех деталей уже не помню.
...
Рейтинг: 0 / 0
05.02.2010, 09:57
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36451200
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Bogdanov AndreyЕгоров АлександрА что тогда делает Ваша система, например, при обработке бизнес-процесса "принять заявку к исполнению" (внутри которого есть бизнес-функция "зарезервировать товар по заявке"), чтобы результат этого процесса отразился у других пользователей системы?Для разработчика бизнес-функций это выглядит, как "Товар.Зарезервировать(количество)". И проблем с пониманием того, что эта запись означает ни у кого не возникает. А учитывая, что среда еще и сама список доступных методов показывает, то и проблем с написанием тоже. И этот разработчик не задумывается о том, что такое "Товар" - просто идентификатор или какая-то сложная структура, о том что делает метод "Зарезервировать" - просто update, или вызывает Web-сервис и рассылает десяток писем и СМС с предупреждениями

жесть конечно, как говорится. Но фоне рассуждений о бизнес-логике, ее устройстве и способах реализации, вдруг всплывают такие подробности. Оказывается разработчики бизнес-логики, понятия не имеют как эта логика работает. Но уверены, что работает круто. Тогда хочется спросить: во время рассказов о скорости разработчки, простоте и прочих чудесах... где скрывались люди, которые пишут внутренности этих самых "Товар.Зарезервировать(количество)"?
...
Рейтинг: 0 / 0
05.02.2010, 10:15
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36451216
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Вставлю свои пять копеек.

Как сделал я когда писал для сети автосалонов. WinForms, ADO.NET, WebServices, MS SQL Server

Тоже первый раз делал трехзвенку, но понимание уже примерное было.
Сделал

1. Морда. Фабрика классов. Управление формами, контроль ввода
2. Среднее звено. Выборка данных из базы по операции и вставка в базу данных по этой же операции
Вебсервис имеет два метода DataSet OpenData(int OID, string Operation) и SaveData(int OID, string Opeation, DataSet Data)
Также фабрика классов. По идентификатору объекта ищется класс, создается экземпляр, находится у него операция и вызывается ее метод выборки данных - Open. Метод виртуальный, для каждого класса своя логика, по большей части наследуется. Метод выбирает все необходимые данные для операции, складывает в один DataSet и возвращает его.
При сохранении у операции вызывается метод Save. Передается туда датасет и класс сам сохраняет данные вызывая соответствующие хранимые процедуры. Там же логика связанная с транзакциями.
3. База данных также имеет фабрику классов и всю логику для работы с данными.

Резюме
1. Логика контроля ввода и манипулирования окнами
2. Логика преобразования из одной структуры в другую. То есть из кучи таблиц в один датасет и обратно. Сюда же приписывается взаимодействие системы с другими системами: почта, импорт-экспорт, что-то еще...
3. Бизнес-логика

--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
05.02.2010, 10:24
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36451267
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
iscrafmжесть конечно, как говорится. Но фоне рассуждений о бизнес-логике, ее устройстве и способах реализации, вдруг всплывают такие подробности. Оказывается разработчики бизнес-логики, понятия не имеют как эта логика работает. Но уверены, что работает круто. Тогда хочется спросить: во время рассказов о скорости разработчки, простоте и прочих чудесах... где скрывались люди, которые пишут внутренности этих самых "Товар.Зарезервировать(количество)"?Я правильно понимаю, что вы с точностью до байта знаете содержание всех сетевых пакетов, которые идут при выполнении резервирования товара, а также сможете сразу перечислить те сектора на диске в которых произойдут изменения? Или вы все-таки тоже пользуетесь разработками других программистов не влезая досконально в их внутренности?
...
Рейтинг: 0 / 0
05.02.2010, 10:42
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36451286
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Bogdanov Andreyiscrafmжесть конечно, как говорится. Но фоне рассуждений о бизнес-логике, ее устройстве и способах реализации, вдруг всплывают такие подробности. Оказывается разработчики бизнес-логики, понятия не имеют как эта логика работает. Но уверены, что работает круто. Тогда хочется спросить: во время рассказов о скорости разработчки, простоте и прочих чудесах... где скрывались люди, которые пишут внутренности этих самых "Товар.Зарезервировать(количество)"?Я правильно понимаю, что вы с точностью до байта знаете содержание всех сетевых пакетов, которые идут при выполнении резервирования товара, а также сможете сразу перечислить те сектора на диске в которых произойдут изменения? Или вы все-таки тоже пользуетесь разработками других программистов не влезая досконально в их внутренности?
нет, сетевые пакеты и секторы на диске меня не интересуют. Утирирование крайне неудачное. Но я с точностью до таблицы, поля в БД, условий, ограничений и т.п. знаю, что делает функция резервирования товара.
...
Рейтинг: 0 / 0
05.02.2010, 10:47
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36451325
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
iscrafmнет, сетевые пакеты и секторы на диске меня не интересуют. Утирирование крайне неудачное. Но я с точностью до таблицы, поля в БД, условий, ограничений и т.п. знаю, что делает функция резервирования товара.Мне своершенно непонятно почему вы остановились именно на таком уровне абстракции. Вы можете как-то обосновать, то что именно до уровня таблиц, полей и т.п. должен доходить разработчик того или иного бизнес-процесса. Почему он не может оперировать классами бизнес-модели или байтами в файлах?
...
Рейтинг: 0 / 0
05.02.2010, 10:57
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36451346
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Bogdanov Andreyiscrafmнет, сетевые пакеты и секторы на диске меня не интересуют. Утирирование крайне неудачное. Но я с точностью до таблицы, поля в БД, условий, ограничений и т.п. знаю, что делает функция резервирования товара.Мне своершенно непонятно почему вы остановились именно на таком уровне абстракции. Вы можете как-то обосновать, то что именно до уровня таблиц, полей и т.п. должен доходить разработчик того или иного бизнес-процесса. Почему он не может оперировать классами бизнес-модели или байтами в файлах?
разработчику бизнес-процесса в это вникать не обязательно. В этом топике речь идет о разработке бизнес-логики. Это немного разные уровни.
...
Рейтинг: 0 / 0
05.02.2010, 11:05
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36451467
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Bogdanov Andrey,

ниже картинка иллюстрирует уровни абстракции.
Сверху - Бизнес-процесс реализации (1). Ниже бизнес логика, реализующая элементы БП. Один из элементов - обработка документов фактической отгрузки, получаемых из системы R/3 (2). Из обработка выполняется функцией (3). Для этого сервер приложений использует процедуру СУБД (4). В СУБД выполняется непосредственная обработка данных (5).
...
Рейтинг: 0 / 0
05.02.2010, 11:35
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36451474
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
Bogdanov AndreyДля разработчика бизнес-функций это выглядит, как "Товар.Зарезервировать(количество)". И проблем с пониманием того, что эта запись означает ни у кого не возникает.Знакомо. Сейчас как раз занимаюсь оптимизацией того, что с делают с базой некоторые среды, предоставляющие разработчику те самые Товар.Зарезвировать(). :) Вот странно, на заре Дельфи, тех, кто делал на ней программы не задумываясь, как именно они работают, называли нехорошими словами. :) Сейчас это мейнстрим. И ни у кого никаких нареканий не вызывает. :) Хотя и сейчас еще считается, что опытный программист подбирает для решения задачи наиболее оптимальный инструмент... А как его можно выбрать, не задумываясь о том что этот инструмент конкретно делает? Не до пакетов в сети, конечно. И не до байтов в памяти, и не до секторов на диске, но хотя бы иметь представление-то надо, иначе это не профессионал, а "формоклепатель" какой-то, как раньше про Дельфийцев и говорили... :)

Не имею ввиду лично Вас.
...
Рейтинг: 0 / 0
05.02.2010, 11:38
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36451500
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Егоров Александр,

Для этого есть очень ёмкое название: 1С-нег :-)
...
Рейтинг: 0 / 0
05.02.2010, 11:46
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36451523
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Егоров АлександрИ не до байтов в памяти, и не до секторов на диске, но хотя бы иметь представление-то надо, иначе это не профессионал, а "формоклепатель" какой-то, как раньше про Дельфийцев и говорили... :)
Да, хороший программист должен не только уметь использовать какие-то вещи, но и понимать как они работают. Но к сожалению, хороших программистов (также как и хороших специалистов в любом деле) очень мало. Большинство занимающихся разработкой - просто тихо делают свою работу без претензий на гениальность. И выбирая арихтектуру серьезного проекта нужно ориентировться именно на эту массу - именно они будут реализовывать в этом проекте разные бизнес-функции, дорабатывать, кастомизиировать и внедрять. Любая архитектура позволяет наисать плохое приложение, но некоторые подходы позволяют минимизировать ущерб от кривых рук.
...
Рейтинг: 0 / 0
05.02.2010, 11:51
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36451549
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Bogdanov Andrey,

Точно, именно поэтому я негативно отношусь к технологиям типа Hibernate, т.к. те, кто ее использует (я имею ввиду прикладников) зачастую не знают, как оптимально писать запросы к базе, абстрагируясь от нее, и тогда на выходе получаем кучу проблем с тормозами в базе.
...
Рейтинг: 0 / 0
05.02.2010, 11:59
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36451553
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Bogdanov Andrey,

В таком случае лучше всю логику помещать или в хранимые процедуры или давать прикладникам уже готовые методы без возможности заглядывания внутрь (черный ящик). Тогда точно не напортачат.
...
Рейтинг: 0 / 0
05.02.2010, 12:01
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36451655
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Old Nickдавать прикладникам уже готовые методы без возможности заглядывания внутрь (черный ящик).Это называется инкапсуляция и вляется одним из столпов объектного программирования. Собственно об этом я уже и пмшу третью страницу.
...
Рейтинг: 0 / 0
05.02.2010, 12:32
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36452142
Не Hibernate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Не Hibernate
Гость
Bogdanov AndreyOld Nickдавать прикладникам уже готовые методы без возможности заглядывания внутрь (черный ящик).Это называется инкапсуляция и вляется одним из столпов объектного программирования. Собственно об этом я уже и пмшу третью страницу.

Бизнес-логика - существенная часть, но сама по себе она мало интересна. Если разделить все на максимально независимые слои(визуальная часть, БЛ, БО, DAL), то появляется гибкость в членах и действительно упрощается разработка. И без ООП здесь не обойтись.
...
Рейтинг: 0 / 0
05.02.2010, 14:41
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36452413
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Не HibernateБизнес-логика - существенная часть, но сама по себе она мало интересна. Если разделить все на максимально независимые слои(визуальная часть, БЛ, БО, DAL), то появляется гибкость в членах и действительно упрощается разработка. И без ООП здесь не обойтись.
без ООП в части реализации DAL, интерфейсов и т.п. - действительно не обойтись, в наше то время. А для БЛ - нужно еще придумать ОО надстройку "сверху" на готовую БЛ, т.е. сделать дополнительно . Зато красиво с программистской точки зрения, типа. Насчет упрощения разработки уже было раньше.
...
Рейтинг: 0 / 0
05.02.2010, 16:11
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36452571
Silverlight
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Silverlight
Гость
iscrafmНе HibernateБизнес-логика - существенная часть, но сама по себе она мало интересна. Если разделить все на максимально независимые слои(визуальная часть, БЛ, БО, DAL), то появляется гибкость в членах и действительно упрощается разработка. И без ООП здесь не обойтись.
без ООП в части реализации DAL, интерфейсов и т.п. - действительно не обойтись, в наше то время. А для БЛ - нужно еще придумать ОО надстройку "сверху" на готовую БЛ, т.е. сделать дополнительно . Зато красиво с программистской точки зрения, типа. Насчет упрощения разработки уже было раньше.
Нет готовых надстроек на все случаи жизни. Зачем нужно еще "сверху" какое-то ОО? Реализуем ЗерезервироватьТовар с помощью того, что проще и забываем про детали. За счет возможности выбора наиболее оптимальных способов и готовых низкоуровневых универсальных частей, упрощается разработка.
...
Рейтинг: 0 / 0
05.02.2010, 16:59
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36452721
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
Bogdanov AndreyДа, хороший программист должен не только уметь использовать какие-то вещи, но и понимать как они работают. Но к сожалению, хороших программистов (также как и хороших специалистов в любом деле) очень мало. Большинство занимающихся разработкой - просто тихо делают свою работу без претензий на гениальность. И выбирая арихтектуру серьезного проекта нужно ориентировться именно на эту массу - именно они будут реализовывать в этом проекте разные бизнес-функции, дорабатывать, кастомизиировать и внедрять. Любая архитектура позволяет написать плохое приложение, но некоторые подходы позволяют минимизировать ущерб от кривых рук.
По сути - согласен. С выделенным - не очень :) На мой взгляд, серьезный проект требует пристального внимания как раз к мелочам. Иначе это может обернуться неожиданными провалами, если условия использования продукта будут хоть немного отличаться от проверенных разработчиком. Хотя в случае с бизнес-приложениями это тоже может не спасти, ведь бизнес меняется достаточно часто. Если продукт узкоспециализированный или даже эксклюзивный - один вариант. Сказал клиент - "максимум 10 заявок", проверили, как ведет себя архитектура на 50-ти - можно спокойно внедрять. Но как быть, если продукт позицируется как массовый? Если у одного заказчика будет максимум 10, а у другого минимум 3000? Не зная архитектуры проверять такое можно только тестированием, а это действительно дополнительные расходы разработчику. Да и не факт что можно протестировать все возможные нагрузки и условия у клиентов. Зная - можно заранее предположить, где и когда возникнут узкие места, и фокусироваться на них (в т.ч. и приглашая дополнительных узких специалистов) по мере приближения к их пределам без остановки развития проекта на других слоях.

Сейчас пришла мысль - а ведь хорошее знание архитектуры как раз и позволяет увидеть в ней определенные слои. То, что с виду кажется монолитным Hibernate - на самом деле такой же "слоеный пирог". Там внутри есть и "прямая работа с БД", есть "бизнес-логика", описывающая правила проекции таблицы в объект и "бизнес-функции" манипулирования этим объектом. Есть "уровень представления", который и использует конечный пользователь разработчик...
Еще пример - "слоеность" современных ОС. "Приложение -> ОС - драйвер -> железо". Более верхний "слой" инкапсулирует более нижний, но возможность работать с каждым слоем позволяет писать программы как используя только доступные API операционки, так и ориентированные на специализированную низкоуровневую обработку железом. Главное - что есть такая возможнось. Фотошоп работает на любой видеокарте, а Doom3 - нет. Но ведь чтобы поиграть совсем необязательно ставить какую-то специальную ОС... :)
...
Рейтинг: 0 / 0
05.02.2010, 18:09
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36452744
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
Old NickДля этого есть очень ёмкое название: 1С-нег :-)

Не провоцируйте :) 1Сник - это прикладной программист на платформе 1С. Как правило, хорошо разбирающийся еще и в предметной области, помимо программирования. И умеющий обходить ограничения этой платформы. ;)

А ёмкое название - это конфигурас :) Они, кстати, бывают и платформонезависимыми ;)
...
Рейтинг: 0 / 0
05.02.2010, 18:21
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36452789
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
SilverlightiscrafmНе HibernateБизнес-логика - существенная часть, но сама по себе она мало интересна. Если разделить все на максимально независимые слои(визуальная часть, БЛ, БО, DAL), то появляется гибкость в членах и действительно упрощается разработка. И без ООП здесь не обойтись.
без ООП в части реализации DAL, интерфейсов и т.п. - действительно не обойтись, в наше то время. А для БЛ - нужно еще придумать ОО надстройку "сверху" на готовую БЛ, т.е. сделать дополнительно . Зато красиво с программистской точки зрения, типа. Насчет упрощения разработки уже было раньше.
Нет готовых надстроек на все случаи жизни. Зачем нужно еще "сверху" какое-то ОО? Реализуем ЗерезервироватьТовар с помощью того, что проще и забываем про детали. За счет возможности выбора наиболее оптимальных способов и готовых низкоуровневых универсальных частей, упрощается разработка.
Вы это не мне говорите. Я об этом с самого начала этой беседы вроде как говорю.
...
Рейтинг: 0 / 0
05.02.2010, 18:55
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36482467
web_fox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
web_fox
Участник
VoDAiscrafmуточните плз, чем отличаются сущности Заказчик, Корпоративный заказчик, Средний, Маленький и т.п. в принципе и чем у них отличается процедура отправки счета, в частности.
С ХП это конечно не в тему, СУБД счета не отправляет.если вы хотите перенести БЛ на СУБД, то СУБД обязана отправлять счета. отправка счета это БЛ.

iscrafmпопытался найти связь аудита действий пользователей с бизнес-логикой, сходу не получилось. Давайте более бизнес-логичные примеры обсуждать.эм... а почему аудит у вас не БЛ? Бизнес-логика это логика системы требуемая для работы компании. Т.е. по сути БЛ это ВСЕ что хочет получить заказчик и за что он платит.

iscrafmестественно не должна. Она и не знает. Банальная валидация ввода.Валидация ввода это тоже БЛ. И кто же должен ее реализовать? А главное ГДЕ?

Рассуждения подобного рода занимают почти весь топик. Грустно.

Коллеги (все участники темы), ваш спор пошёл от того, что вопрос о том, должна ли распологатиься бизнес-логика в БД, НЕКОРЕКТЕН и обсуждать его в такой постановке безсмысленно.

Объясняю. Система управления базами данных специализируется на управлении базами данных, поэтому делает это в общем случае это априри эффективнее. Но, не всякая логика требует средств СУБД.

Вывод: на хранимые процедуры СУБД переносится ТОЛЬКО логика, которая относится к обработке данных хранимых в БД.

Поэтому очень не стоит переносить на ХП логику игры Quake (непрофильное использование, хотя практически возможное!), как очень стоит переносить на ХП работу с данными, которые хранятся в БД (профильное использование). А за программирование масовой обработки данных из БД на уровне сервера приложений первый раз нужно предупреждать, а второй - увольнять.

Лично у нас принято правило: "все обращения к БД только через ХП", а это кардинально отличается по смыслу от "вся бизнес-логика на ХП".

Удачи, коллеги.
...
Рейтинг: 0 / 0
22.02.2010, 00:19
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36482996
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
web_foxЛично у нас принято правило: "все обращения к БД только через ХП", а это кардинально отличается по смыслу от "вся бизнес-логика на ХП". Можете обосновать это правило какими-нибудь разумными, нерелигиозными причинами?
Почему вызов insertTable(id=>1,label=>'one') лучше, чем insert into table(id, Label) values(1,'one') ?
...
Рейтинг: 0 / 0
22.02.2010, 14:49
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36483064
Фотография Шайтан
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Шайтан
Участник
web_fox Лично у нас принято правило: "все обращения к БД только через ХП", а это кардинально отличается по смыслу от "вся бизнес-логика на ХП".
+1
БЛ в ХП - полнейший изврат

Шайтан
...
Рейтинг: 0 / 0
22.02.2010, 15:28
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36483080
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
скорее "все обращения к БД только через ХП" полный изврат.
...
Рейтинг: 0 / 0
22.02.2010, 15:38
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36483454
web_fox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
web_fox
Участник
Bogdanov Andreyweb_foxЛично у нас принято правило: "все обращения к БД только через ХП", а это кардинально отличается по смыслу от "вся бизнес-логика на ХП". Можете обосновать это правило какими-нибудь разумными, нерелигиозными причинами?
Почему вызов insertTable(id=>1,label=>'one') лучше, чем insert into table(id, Label) values(1,'one') ?

На этом форуме это обсуждали много раз. Квалифицированные разработчики как на меня. Имеено на ваш вопрос, процитирую из этого форума, например такой отрывок очень опытного разработчика:
prustrА есть какие-то разумные обоснования такой обертке инсертов/апдейтов?
- Есть. Структура базы почти всегда требует изменений, что там прибаляется что-то убавляется... обычный жизненный цикл. Если запросы упакованы в процедуры, то с клиентом согласовывется только структура передаваемых данных. колонки и типы. Изменения алгоритмов обработки в базе не влияют на работу клиентов, делаются на лету.
Иначе надо переписывать и клиента и БД, а это очень неудобно в плане сохранения работоспособности проекта во время обновления версий.

PS: никакой релиигии здесь нет и быть не может, только опыт. Я рекомендую вам делать только то, что вы понимаете . Если это не понятно - лучше не использовать.
...
Рейтинг: 0 / 0
22.02.2010, 19:23
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36483478
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
web_foxprustrА есть какие-то разумные обоснования такой обертке инсертов/апдейтов?
- Есть. Структура базы почти всегда требует изменений, что там прибаляется что-то убавляется... обычный жизненный цикл. Если запросы упакованы в процедуры, то с клиентом согласовывется только структура передаваемых данных. колонки и типы. Изменения алгоритмов обработки в базе не влияют на работу клиентов, делаются на лету.
Иначе надо переписывать и клиента и БД, а это очень неудобно в плане сохранения работоспособности проекта во время обновления версий.

PS: никакой релиигии здесь нет и быть не может, только опыт. Я рекомендую вам делать только то, что вы понимаете . Если это не понятно - лучше не использовать.
ответ совершенно не в тему. Тем более, когда речь идет об изменении структуры БД, которые естественно должны быть отражены в этих самых "инсертах/апдейтах" и, естественно, в структуре передаваемых данных. Невпопад как-то. Воспользуйтесь своей же рекомендацией.
...
Рейтинг: 0 / 0
22.02.2010, 19:35
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36483700
web_fox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
web_fox
Участник
Bogdanov Andrey,

Кстати, вот здесь, по-моему рассмотрено большинство преимуществ такого разделения:
/topic/724491&pg=1

Лично мы прошли через все упомянутые в теме трудности (кроме масштабирования), пока не пришли к упомянутому правилу использования ХП. Также озвучу какие выгоды на нашем опыте позволили ускорить разработку и уменьшить отладку:
1. Наибольший выигрыш мы получили от того, что БД-разработчик мог разрабатывать логику работы с данными независимо от разработчика среднего слоя. Независимо мог менять логику, так что не приходилось изменять клиентов. На продакшене это очень гибкий подход оказался. Плюс, чёткое разделение профнавыков программистов, иначе "любой из наших JAVA программистов просто превратится в DBA поневоле, с соответствующей дефицитностью и окладом". Отдельный человек разрабатывает интерфейс, отдельный - БД с ХП, отдельный - средний слой. Каждый занимается своим делом. При этом разработчику среднего слоя БД-программист просто передавал спецификацию пакетов с комментариями о назначении функций, не приходилось обьяснять в какие таблицы что писать, какие физические и логические связи между таблицами и т.п. Человек проектировал БД, создавал таблицы и функции и передавал работу дальше. За функцией мог скрываться как простейший инсерт, так и сложнейшая логика по массовой обработке данных - полная инкапсуляция логики для работы с БД.
2. Второй важный выигрыш: весь программный код, который обращается к таблицам находится в одном месте - в СУБД. Те же Oracle, DB/2 (и др возможно) позволяют отслеживать связи, так что при рефакторинге никогда не встанет вопрос перелапачивания мегабайтов php-кода с целью понять кто использует "эту" таблицу и что он там в неё пишет. Просто выбираете в контекстном меню на таблице пункт "посмотреть связи" и видно все функции, которые используют данную таблицу. Даже если пришлось кому-то написать динамический SQL, то через системные представления такой код легко находится.

Подход оказался на редкость удачным. Возможно для вас это не актуально, я спорить или навязывать ни в коем случае не собираюсь, это только мой опыт.
...
Рейтинг: 0 / 0
22.02.2010, 21:56
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36483764
Senya_L
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Senya_L
Участник
web_foxПлюс, чёткое разделение профнавыков программистов, иначе "любой из наших JAVA программистов просто превратится в DBA поневоле, с соответствующей дефицитностью и окладом". Отдельный человек разрабатывает интерфейс, отдельный - БД с ХП, отдельный - средний слой. Каждый занимается своим делом .А не выходит так, что разработчик одного из слоя ждет исполнителя другого слоя? Спрашиваю без критицизма, просто интересно.
...
Рейтинг: 0 / 0
22.02.2010, 22:57
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36483770
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
web_fox1. Наибольший выигрыш мы получили от того, что БД-разработчик мог разрабатывать логику работы с данными независимо от разработчика среднего слоя. Независимо мог менять логику, так что не приходилось изменять клиентов. На продакшене это очень гибкий подход оказался. Плюс, чёткое разделение профнавыков программистов, иначе "любой из наших JAVA программистов просто превратится в DBA поневоле, с соответствующей дефицитностью и окладом". Отдельный человек разрабатывает интерфейс, отдельный - БД с ХП, отдельный - средний слой.
а в чем заключается работа "разработчика среднего слоя". По тому, что Вы описали, такого "человека" просто не получается.
...
Рейтинг: 0 / 0
22.02.2010, 23:04
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36483835
web_fox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
web_fox
Участник
Senya_Lweb_foxПлюс, чёткое разделение профнавыков программистов, иначе "любой из наших JAVA программистов просто превратится в DBA поневоле, с соответствующей дефицитностью и окладом". Отдельный человек разрабатывает интерфейс, отдельный - БД с ХП, отдельный - средний слой. Каждый занимается своим делом .А не выходит так, что разработчик одного из слоя ждет исполнителя другого слоя? Спрашиваю без критицизма, просто интересно.

Такого быть никак не может. Есть руководители проектов, общий пул ресурсов и планы проектов - всё распланировано, никто не втыкает. Специалисты по БД проектируют и реализуют много всего разного, от OLTP и логики работы с данными, до ETL/хранилищ данных. Работы их профиля море. Бизнес в телекоме очень динамичный, IT-департамент стоит на конвеере, проекты расписаны на 5 лет вперёд. За счёт такого разделения много выигрышей, как при феодальном строе выигрыш от разделения труда - эти сеют, эти пашут, эти ткут. Программисты средних слоёв обычно не настолько хорошо разбираются в БД, чтобы настолько профессионально проектировать таблицы, разбирать планы запросов, анализировать статистику, владеть хинтами, выбирать в нужный час битмеп-индексы, сегментирования, материальные представления - это отдельная епархия, это люди, которые сруки используют аналитические функции, цитируют Тома Кайта и следят за конференциями связанными с БД, они мастера своего дела и пишут качественный код. Java, C#, PHP-прогеры и прочие болеют совсем другими вещами, решают задачи в которых профессионалы они.
...
Рейтинг: 0 / 0
22.02.2010, 23:49
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36484460
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
web_fox1. Наибольший выигрыш мы получили от того, что БД-разработчик мог разрабатывать логику работы с данными независимо от разработчика среднего слоя.
Много вы букв написали. Попробую прокомментировать.

web_foxНезависимо мог менять логику, так что не приходилось изменять клиентов.Если логика реализована в БД, то естественно надо вызывать процедуры выполняющие эту логику. Но вы выдвигаете "абсолютное" требование - любое обращение к БД через ХП. Если клиент должен вставить запись в таблицу, то значит он должен ее вставить и никакой другой логики здесь нет. Если завтра бизнес-логика потребует вставки в другую таблицу, то в вашем подходе клиента точно также придется менять вставив внего вызов insertTableB вместо insertTableA. Единственный случай, когда ваш подход "работает" - если таблицу просто переименовывают без какого-либо изменения ее назначения. Сам по себе действие бессмысленное, но и оно гораздо проще решается созданием вьюшки.
Я так понимаю, что вы путаете интерфейс к данным с интерфейсом к логике.

web_foxПри этом разработчику среднего слоя БД-программист просто передавал спецификацию пакетов с комментариями о назначении функций, не приходилось обьяснять в какие таблицы что писать, какие физические и логические связи между таблицами и т.п. Я правильно понимаю, что обяснить сделай "insert into..." существенно сложнее, чем вызови процедуру "insertInto". Неужели все так плохо с разработчиками среднего слоя?

web_foxполная инкапсуляция логики для работы с БД.С равным (и даже большим, ввиду большей гибкости языков програмирования) успехом инкапсуляция работы с БД достигается на стороне "среднего" слоя.

web_fox2. Второй важный выигрыш: весь программный код, который обращается к таблицам находится в одном месте - в СУБД. Те же Oracle, DB/2 (и др возможно) позволяют отслеживать связи, так что при рефакторинге никогда не встанет вопрос перелапачивания мегабайтов php-кода с целью понять кто использует "эту" таблицу и что он там в неё пишет. Просто выбираете в контекстном меню на таблице пункт "посмотреть связи" и видно все функции, которые используют данную таблицу. Даже если пришлось кому-то написать динамический SQL, то через системные представления такой код легко находится.Хорошие костыли для неумения работать с исходными кодами. Особенно порадовал поиск в системных представлениях. :) То есть перелопатить мегабайты pl/sql кода проблемы не представляет, а вот с php-кодом - сложности.
Я правильно понимаю, что понять кто из среднего слоя выполняет Insert into table вы не можете, а кто вызывает процедуру insertTable - умете?

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

Давайте попробуем на конкретном примере. Пусть мне надо сделать, скажем, справочник валют. Я в СУБД просто сделаю таблицу Currency(Id, Name, CodeISO). Пользовательский интерфейс для ведения справочника "руками" будет делать одни запросы. Механизм загрузки из файла - другие и т.п. А сколько процедур вам понадобиться? И какие конкретно проблемы эти процедуры смогут решить?
...
Рейтинг: 0 / 0
23.02.2010, 15:53
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36484582
Кифирчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кифирчик
Участник
Bogdanov AndreyЯ правильно понимаю, что обяснить сделай "insert into..." существенно сложнее, чем вызови процедуру "insertInto". Неужели все так плохо с разработчиками среднего слоя?
угу... я тоже сперва думал что INSERT это просто INSERT, и писал (к примеру)
INSERT INTO dbo.a_flat_list
( street_id, build_num, build_char, room_num, room_char,flat_num ) VALUES (....);

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
CREATE PROCEDURE [dbo].[proc_flat_add_new]
@street_id  int ,
@build_num  int ,
@build_char varchar( 2 ),
@room_num   int ,
@room_char  varchar( 2 )
AS
BEGIN
   DECLARE @retry    INT;
   DECLARE @err_msg  VARCHAR( 255 );
   DECLARE @err_proc VARCHAR( 100 );
   DECLARE @log_msg  VARCHAR( 255 );
   DECLARE @flat_id  INT;

   SET @retry   =   5 ;
   
   SET NOCOUNT ON;
   SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
   SET LOCK_TIMEOUT  1000 ;
   
   if @build_num =  0  set @build_num = null;
   if @room_num  = 0   set @room_num  = null;
   
   
   -- проверит что квартиры с такими буквами и номерами нет в базе
   SELECT @flat_id = a.flat_id
   FROM dbo.a_flat_list a
   WHERE a.street_id  = @street_id
   AND   a.build_num  = @build_num
   AND   a.build_char = @build_char
   AND   a.room_num   = @room_num
   AND   a.room_char  = @room_char;
   
   if @flat_id >  0  begin
     set @err_msg = 
       'Такая квартира (частный дом) уже существует '+CHAR( 13 )+CHAR( 10 )+
       'Выполнение операции невозможно';
     if @@TRANCOUNT >  0  rollback;raiserror(@err_msg,  16 ,  1 );return;       
   end;  
   
   WHILE (@retry >  0 )
   BEGIN
     BEGIN TRY
       BEGIN TRANSACTION;  
       --------------------------------------------------------------
       SELECT @flat_id=- 1  FROM dbo.a_flat_list   WITH(TABLOCK);
       SELECT @flat_id=- 1  FROM dbo.a_street_list WITH(TABLOCK);
       
       INSERT INTO dbo.a_flat_list 
       ( street_id, build_num, build_char, room_num, room_char,
         flat_num 
        )
       VALUES
       ( @street_id,@build_num,@build_char,@room_num,@room_char,
        dbo.fun_get_addrnum(
                    @build_num,@build_char,@room_num,@room_char)
        );
       
       SELECT @flat_id=SCOPE_IDENTITY();
       
       SELECT @flat_id AS flat_id;
       --------------------------------------------------------------
       SET @retry = - 5 ;
       COMMIT TRANSACTION;
     END TRY BEGIN CATCH 
       SET @err_msg = dbo.fun_get_error_info();SET @err_proc = ERROR_PROCEDURE();
       IF((ERROR_NUMBER() =  1205 )OR(ERROR_NUMBER() =  1222 ))  
            SET @retry = @retry -  1 ;           
       ELSE SET @retry = - 1 ;
       IF XACT_STATE() <>  0  ROLLBACK TRANSACTION;
     END CATCH;
   END; -- End WHILE loop.
   IF @retry <> - 5  BEGIN 
      EXEC dbo.proc_log_add_error @err_proc,@err_msg;RAISERROR(@err_msg, 16 , 1 );RETURN;
   END;
   SET @log_msg = 'flat_id='+convert(varchar, @flat_id);
   EXEC dbo.proc_log_add  0 ,'proc_flat_add_new',@log_msg;
   SELECT @flat_id;
END
после, для себя взял за правило, если есть возможность - все только через хранимки, и обязательно все действия в логи.
...
Рейтинг: 0 / 0
23.02.2010, 17:19
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36484614
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
жесть, как говорится
...
Рейтинг: 0 / 0
23.02.2010, 17:52
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36484641
web_fox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
web_fox
Участник
Bogdanov Andrey,

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

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

Возьмите, пожалуйста, бумагу и нарисуйте два слоя: Слой БД и Клиента.

Вариант1: Клиент использует БД-функцию GetCurrencyById(Id):ArrayOfProperty.
Вариант2: Клиент напрямую читает из таблиц БД.

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

Вариант1: Меняется логика функции. Для клиента всё остаётся прозрачно.
Вариант2: Меняется логика функции. Нужно изменить клиента тоже.

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

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

Или у вашей компании не хватает денег, чтобы отдельно нанять БД-разработчика и не заставлять людей учить признаки, при которых нужны битмеп-индексы (кстати, вы знаете что это такое?), или лично у вас опыт написания только простейших проектов, а ля погонять справочники туда-сюда.
...
Рейтинг: 0 / 0
23.02.2010, 18:11
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36484647
web_fox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
web_fox
Участник
Кифирчик,

во, видно опытного человека. Причём очевидно, что если бы данная логика была на клиенте, то запросов бы в базу было несколько, а так один.
...
Рейтинг: 0 / 0
23.02.2010, 18:15
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36484655
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
web_fox,

web_foxВижу, что вы не понимаете этих вещей просто по неопытности. Это не в обиду, но вопросы выглядят просто незрелыми, да ещё с оттенком задаваки
...
Рейтинг: 0 / 0
23.02.2010, 18:19
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36484705
web_fox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
web_fox
Участник
авторSQL-интерфейс к реляционным данным гораздо более гибок, удобен и надежен. Никакими храниммыми процедурами не реализовать и половины его возможностей.

Из это предложения следует, что вы не понимаете что пишите. Студент? 8)
...
Рейтинг: 0 / 0
23.02.2010, 18:45
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36484743
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
web_fox,
речь идет о динамическом SQL, который формируется инструментами "среднего слоя". Вы не понимаете о чем вообще речь идет. Студент?
...
Рейтинг: 0 / 0
23.02.2010, 19:09
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36484788
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
банальная задачка: есть набор записей, в котором по определенному условию нужно заменить значение одного, допустим, поля. Полагаю, что коллега Bogdanov Andrey динамически сформирует update...where и передаст серверу СУБД на исполнение. А что нужно сделать в случае следования принципу "все модификации БД только через ХП"?
Варианты ответа:
1. Написать очередную ХП для выполнения этого действия
2. Поочередно отредактировать каждую запись, которая вызовет назначенную для этого действия ХП. Тяжело? А кому сейчас легко.
3. Написать нечто с динамически изменяемым набором параметров и динамически формируемым SQL в ХП
4. А нафига это вообще нужно.
...
Рейтинг: 0 / 0
23.02.2010, 19:37
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36485113
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
Одна из составных частей бизнес-логики - валидация вводимых значений.

Вопрос, где должна быть эта часть бизнес-логики если:

1. К базе данных обращаются разные программы
2. Клиент должен поддерживать хотя бы частичную работу оффлайн
3. Трафик между клиентом и МТ требуется минимизировать
4. Некоторые проверки требуют обработки больших массивов информации
5. Все выше перечисленное?

Наводящий вопрос: На каком элементе трехзвенки можно НЕ имплементировать валидацию в ситуации (5)?
...
Рейтинг: 0 / 0
24.02.2010, 09:05
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36485163
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
drev,

если отбросить вопрос о валидации ввода, как о составной части бизнес-логики, то наводящий вопрос: о чем речь идет?
...
Рейтинг: 0 / 0
24.02.2010, 09:50
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36485193
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
iscrafmdrev,

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

А вы попробуйте не отбрасывать:)

Ответив на поставленные мной вопросы, можно определить на каких тирах нам нужно иметь бизнес-логику, а на каких - необязательно.
...
Рейтинг: 0 / 0
24.02.2010, 10:09
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36485231
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
dreviscrafmdrev,

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

А вы попробуйте не отбрасывать:)

Ответив на поставленные мной вопросы, можно определить на каких тирах нам нужно иметь бизнес-логику, а на каких - необязательно.
чтобы ответить на эти вопросы и не отбрасывать определение валидации, ответьте на наводящие вопросы.
Есть форма ввода транзакции по платежной карте. В качестве входящих данных требуется номер карты, имя владельца, срок действия, CVV2-код. Что вы относите к валидации ввода?
Судя по вопросам - процедуру авторизации транзакции? Или все же проверку того, чтобы номер какрты состоял из 16 цифр, а cvv2 из 3-х и т.п.?
...
Рейтинг: 0 / 0
24.02.2010, 10:31
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36485288
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
немного расшифрую вопрос...
часто путают понятия валидация и верификация, аутентификация и авторизация и т.п. Само сочетание "валидация ввода" звучит немного корявенько, поэтому хочется понять о чем идет речь. Если о проверке вводимых значений, то клиент именно то место, где такой проверке самое место (тавтология). Если речь идет о проверке возможности применения в системе введенной (полученной другими способами входящей информации) то это как раз и является предметом спора в данной теме. Тогда лучше выскажите свое мнение по данному вопросу.
...
Рейтинг: 0 / 0
24.02.2010, 10:52
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36486597
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Кифирчикугу... я тоже сперва думал что INSERT это просто INSERT, и писал (к примеру)...Сразу видно человека который не отличает бизнес-логику от данных. Прмер, в котором ХП реализуют бизнес-логику никак не доказывает того, что вся работа с данными должна вестись через процедуры.

web_foxВариант1: Клиент использует БД-функцию GetCurrencyById(Id):ArrayOfProperty.
Вариант2: Клиент напрямую читает из таблиц БД.

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

web_foxСмотрим что получается.А теперь смортим еще и замечаем, что надо сделать загрузку валют из текстового файла.

Вариант1: Создаем новую функцию GetCurrencyByCode и меняем клиента
Вариант2: Просто меняем клиента.

Затем в табличку добавляется поле CodeISONum (для всех валют есть цифровые коды).
Вариант1: Переписываем функцию и меняем клиента
Вариант2: Просто меняем клиента.

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

web_fox- мы ближе к "идеально разработанной системе" (чем лучше спроектирована система, тем меньше нужно сделать изменений при изменении бизнес-процесса). Мы поменяли один слой, а не два - это быстрее, это удобней, это понятней, а для продакшн-системы минимизация рисков при накатывании релизов.Я еще раз повторю - покажите мне реальные примеры, пока были только теоретизирования. И пожалуйста, без примеров бизнес-логики в ХП. Пока же я вижу, что 90% всех изменений у вас гарантированно затроет и БД и СП. Еще примерно 10% затронут только СП, ну и оставшееся на случай изменения только в БД. В моем варианте примерно 60%-70% изменений затрагивают только СП. Очевидный выигрыш моего варианта по данному показателю.

web_foxвсе обращения к таблицам только в БД - видны мгновенно все функции, которые их используют. Не нужно искать код, который использует эти таблицы в клиенте - всё централизовано, все используют функции БД.Ну тут вы просто врете. Нифига "мгновенно" не видно. Во первых, вы сами писали про динамический sql, а во вторых вы никак не решаете задачу нахождения тех, кто использует ваши функции.

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

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

web_foxИли у вашей компании не хватает денег, чтобы отдельно нанять БД-разработчика и не заставлять людей учить признаки, при которых нужны битмеп-индексыЯ правильно понимаю, что написать insert into table без знания bitmap-индексов никак нельзя...

web_fox (кстати, вы знаете что это такое?), или лично у вас опыт написания только простейших проектов, а ля погонять справочники туда-сюда.Ага, сейчас будем проектами меряться. Может быть сначала про свой богатейший опыт расскажете? А то ведь такие умные слова знаете, "битмап"...
...
Рейтинг: 0 / 0
24.02.2010, 19:01
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36486605
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
drev1. К базе данных обращаются разные программыЕсли разные программы обращаются именно к базе данных, то естественно, что база данных должна представлять собой целостный сервис и все проверки обеспечивающие эту целостность должны быть в БД.

Но обычно (по крайней мере в последнее время), если одними данными пользуется несколько разных программ, то существует некий централизованный сервер приложений, предоставляющий им интерфейсы.
...
Рейтинг: 0 / 0
24.02.2010, 19:09
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36486833
Кифирчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кифирчик
Участник
Bogdanov AndreyКифирчикугу... я тоже сперва думал что INSERT это просто INSERT, и писал (к примеру)...Сразу видно человека который не отличает бизнес-логику от данных. Прмер, в котором ХП реализуют бизнес-логику никак не доказывает того, что вся работа с данными должна вестись через процедуры.

обалдеть, ну так вы в цитату фразу вставьте, пытаясь ответить на которую, я привел пример

Bogdanov AndreyКифирчикBogdanov Andrey
Я правильно понимаю, что обяснить сделай "insert into..." существенно сложнее, чем вызови процедуру "insertInto". Неужели все так плохо с разработчиками среднего слоя?
угу... я тоже сперва думал что INSERT это просто INSERT, и писал (к примеру)...Сразу видно человека который не отличает бизнес-логику от данных. Прмер, в котором ХП реализуют бизнес-логику никак не доказывает того, что вся работа с данными должна вестись через процедуры.
вы это вообще о чем?...
какая бизнес-логика? я просто првел пример, что ОЧЕНЬ часто, нельзя из программы просто писать INSERT INTO, и это черевато проблемами.
И если "по нормальному", то прежде чем написать INSERT INTO, программисту надо запустить транзацию, залочить нужные таблицы, сделать проверки, и незабыть обработать исключительные ситуации с обязательными rollback в случае чего.
А в данном примере, надо только вызвать хранимую процедуру - 5..7 строчек кода, и более того, для "сущности" есть класс, с именами как в базе, и когда надо добавить новую, просто пишется
Код: plaintext
1.
2.
flat_item.street_id :=  10 ;
flat_item.build_num :=  7 ;
flat_item.proc_flat_add_new();
Так что хранимку вызвать точно проще чем INSERT INTO "как надо"...

на счет битмэп не знаю, но без знания хинтов... с INSERT.. написать можно, но я бы не подпускал :-)

И даже если бы мне надо было разбить приведенное выше приложение, на 3 уровня, то в сервере приложений (к примеру для работы через XML, для нестабильных соединений, чтоб не держать простоянный коннект) я бы сделал "обертку" для базы, с всякими буфферизациями, кэшированием... логику оставил бы в базе.
Именно для этого приложения, оптимум - логика в базе.
Конечно не исключаю, что в других случаях будет наоборот.
...
Рейтинг: 0 / 0
24.02.2010, 22:02
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36486888
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Кифирчикобалдеть, ну так вы в цитату фразу вставьте, пытаясь ответить на которую, я привел примерЛегко.
Вы отвечали на мой пост в котором сказано:
"Если логика реализована в БД, то естественно надо вызывать процедуры выполняющие эту логику. Но вы выдвигаете "абсолютное" требование - любое обращение к БД через ХП."

При этом в качестве оппонирующего аргумента (то бишь поддерживая абсолютизацию ХП) вы пишите:
КифирчикИменно для этого приложения, оптимум - логика в базе.
Если уж отвечаете на пост, то читайте его целиком, а не кусками.

Кифирчиквы это вообще о чем?...
какая бизнес-логика?
Вообще-то я плохо разбираюсь в MSSQL, но открытие и завершение транзакции внутри ХП для меня однонзачно указывает на то, что данная процедура реализует некоторый целостный кусок бизнес-логики, а никак не отдельную интерфейсную операцию базы данных.
...
Рейтинг: 0 / 0
24.02.2010, 22:50
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36486930
Кифирчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кифирчик
Участник
Bogdanov Andrey[
Кифирчиквы это вообще о чем?...
какая бизнес-логика?
Вообще-то я плохо разбираюсь в MSSQL, но открытие и завершение транзакции внутри ХП для меня однонзачно указывает на то, что данная процедура реализует некоторый целостный кусок бизнес-логики, а никак не отдельную интерфейсную операцию базы данных.
Когда с базой работает один пользователь - это все лишнее...
но когда их много, могут возникнуть проблемы при обращении к одним ресурсам...
когда кто-то вызвал "UPDATE", в MSSQL, как блокировочнике, таблица "блокируется" пока этот апдейт не выполнится... и когда туда тыркаются другие, они получают болт...
так вот "блокировка" должна распонзаваться и соответсвующим образом обрабатываться, что и приведено в примере... само собою и элементы логики надо в это оборачивать
иначе, возникают всякие висячие транзакции, заблокированные ресурсы, ролбэки, охватывающие час работы всех пользователей... ох я шишок в начале с этим набил...

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

отвечая на ваш пост, я не абсолютизировал "доступ к БД" через хранимки, я хотел сказать, что в некоторых случаях без хранимок либо вообще ни как, либо очень тяжко, даже еcли отбросить логику и говорить о простых INSERT
...
Рейтинг: 0 / 0
24.02.2010, 23:27
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487042
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
Кифирчиккогда кто-то вызвал "UPDATE", в MSSQL, как блокировочнике, таблица "блокируется" пока этот апдейт не выполнится... и когда туда тыркаются другие, они получают болт...Смелое утверждение. Не поделитесь источником "знаний" ?
...
Рейтинг: 0 / 0
25.02.2010, 02:02
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487103
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
iscrafmнемного расшифрую вопрос...
часто путают понятия валидация и верификация, аутентификация и авторизация и т.п. Само сочетание "валидация ввода" звучит немного корявенько, поэтому хочется понять о чем идет речь. Если о проверке вводимых значений, то клиент именно то место, где такой проверке самое место (тавтология). Если речь идет о проверке возможности применения в системе введенной (полученной другими способами входящей информации) то это как раз и является предметом спора в данной теме. Тогда лучше выскажите свое мнение по данному вопросу.


ИМХО, не все так просто, как Вы пишите.

Рассмотрим, например, сумму транзакции:

Правило первое: "Если транзакция инициирована в банкомате, то сумма таких транзакций за день не может превышать Х(например - $500).

Очевидно, что из этого следует, что любая атомарная транзакция в банкомате не может превышать $500. Эту проверку можно и нужно провести на клиенте.

Более того, после проверки пин-кода можно передать на клиент сумму уже произведенных трамзакций за день и провести полную проверку (возможность этого действия определяется из стандартов безопасности). В любом из вариантов, эту же проверку нужно провести на сервере (ИМХО, в БД).

Таким образом мы видим, что одно и то же бизнес-правило применяется дважды - на клиенте(для удобства пользователя и уменьшения числа раунд-трипов) и на сервере(БД) (для поддержания целостности).

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

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

Правило третье. "при выполнении условия Х (например, сумма депозита более $10.000) необходимо сообщить по адресу alert@irs.gov".

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

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

Я ответил на Ваш вопрос?
...
Рейтинг: 0 / 0
25.02.2010, 06:54
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487104
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
Bogdanov Andreydrev1. К базе данных обращаются разные программыЕсли разные программы обращаются именно к базе данных, то естественно, что база данных должна представлять собой целостный сервис и все проверки обеспечивающие эту целостность должны быть в БД.

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

К сожалению, это "обычно" мне практически не встречалось
...
Рейтинг: 0 / 0
25.02.2010, 06:58
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487129
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
КифирчикКогда с базой работает один пользователь - это все лишнее...
но когда их много, могут возникнуть проблемы при обращении к одним ресурсам...
...skipped...
в свете описанных сложностей, я вообще смутно представляю, как в таких ситуациях без хранимок, это наверно только в сайтах, где не особо с конкурентным доступом, программист может просто в коде написать INSERT...
я бы посмотрел как бы это прокатило в какой-нить системе бронирования билетов )
Некоторые сложности могут встречаться, но все они легко решаются и безо всяких хранимок. А вот то, что ваша хранимка уже не позволяет организовать нормальные транзакции - факт. Если бизнес-логика требует, чтобы адрес появлялся только вместе с его обладателем, то придется вам новую хранимку писать или эту переписывать.
А уж в системе бронирования билетов без нормальных транзакций точно не обойтись. Там надо в одной транзакции и место забронировать и денежную операцию оформить и какие-нибудь бонусы рассчитать. А у вас на каждый insert - своя процедура с begin transaction. Посмотрел бы я как это в системе бронирования прокатит.

Кифирчикотвечая на ваш пост, я не абсолютизировал "доступ к БД" через хранимки,
Дискуссия возобновилась с высказывания web_fox: "все обращения к БД только через ХП". Это весьма категоричное и абсолютное высказываение. Как мне показались, вы выступили в поддержку web_fox. Я правильно понимаю, что мне показалось неправильно, и вы отнюдь не считаете, что все обращения к БД должны идти через хранимки?

Кифирчикя хотел сказать, что в некоторых случаях без хранимок либо вообще ни как, либо очень тяжко, даже еcли отбросить логику и говорить о простых INSERTЕсли отбросить логику то от вашей хранимки вообще ничего не останется.
Естественно, иногда хранимые процедуры оказываются весьма удобным инсрументом. Иногда они позволяют упростить код, иногда соптимизировать. Но задач, которые бы не решались без них - нет.
...
Рейтинг: 0 / 0
25.02.2010, 07:56
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487173
Кифирчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кифирчик
Участник
Bogdanov AndreyА вот то, что ваша хранимка уже не позволяет организовать нормальные транзакции - факт.
ой... а с чего вы так решили?

Bogdanov AndreyЕсли бизнес-логика требует, чтобы адрес появлялся только вместе с его обладателем, то придется вам новую хранимку писать или эту переписывать.
пришлось бы.... ну и?
а... кажется понял, это вы к тому, что если без хранимок, то вы только в одном "слое" внесли бы изменения, а тут надо и хранимку переделать, и в её вызове на клиенте добавить несколько параметров.. ну да... это очень сложно

Bogdanov AndreyДискуссия возобновилась с высказывания web_fox: "все обращения к БД только через ХП". Это весьма категоричное и абсолютное высказываение. Как мне показались, вы выступили в поддержку web_fox. Я правильно понимаю, что мне показалось неправильно, и вы отнюдь не считаете, что все обращения к БД должны идти через хранимки?
да, все подряд обращения, и во всех возможных ситуациях, делать черех хранимки не стоит, но иногда без них не обойтись, я привел пример с INSERT

Bogdanov AndreyНо задач, которые бы не решались без них - нет.
... в смысле вам не попадались
...
Рейтинг: 0 / 0
25.02.2010, 08:56
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487284
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
drev
Я ответил на Ваш вопрос?
Вы описали обычные процедуры бизнес-логики. К проверке ввода не имеющие отношения. Все действия действительно выполняются на сервере, ну разве что, применительно к банкомату, проверка максимальной суммы атомарной транзакции, заданной как параметр. Для остального - связь с сервером.

drevПравило второе: "Сумма снятия не должна превышать остаток на счету более чем на предел овердрафта, установленный для данного пользователя".
Опять же, предварительную проверку можно провести на клиенте, но окончательная должна быть обеспечена на уровне БД.
какие еще предварительные проверки овердрафта на клиенте? шутить изволите.
...
Рейтинг: 0 / 0
25.02.2010, 09:57
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487296
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
как же все-таки поступят адепты утверждения "все только на хранимках"?
...
Рейтинг: 0 / 0
25.02.2010, 10:03
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487312
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
КифирчикBogdanov AndreyЕсли бизнес-логика требует, чтобы адрес появлялся только вместе с его обладателем, то придется вам новую хранимку писать или эту переписывать.
пришлось бы.... ну и?
а... кажется понял, это вы к тому, что если без хранимок, то вы только в одном "слое" внесли бы изменения, а тут надо и хранимку переделать, и в её вызове на клиенте добавить несколько параметров.. ну да... это очень сложно

если есть желание, образно, "за теже деньги" постоянно переписывать и добавлять ХП, то конечно не сложно. Но все же более нормально выглядит "работать меньше за теже деньги"
...
Рейтинг: 0 / 0
25.02.2010, 10:10
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487381
Кифирчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кифирчик
Участник
iscrafm как же все-таки поступят адепты утверждения "все только на хранимках"?
рискну предположить, что напишут очередную ХП для этого действия, и возможно, если будет изменяемое колличество параметров, внутри будет динамичекский SQL

а что подразумевается под
iscrafmбанальная задачка: ...
2. Поочередно отредактировать каждую запись, которая вызовет назначенную для этого действия ХП. Тяжело?
?
...
Рейтинг: 0 / 0
25.02.2010, 10:40
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487423
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Кифирчикiscrafm как же все-таки поступят адепты утверждения "все только на хранимках"?
рискну предположить, что напишут очередную ХП для этого действия, и возможно, если будет изменяемое колличество параметров, внутри будет динамичекский SQL

а количество параметров тоже динамически изменяемое? Или парсер напишут?

Кифирчика что подразумевается под
iscrafmбанальная задачка: ...
2. Поочередно отредактировать каждую запись, которая вызовет назначенную для этого действия ХП. Тяжело?
?
подразумевается то, что и написано. пройтись по записям выборки и вызвать для каждой UPDATE-процедуру
...
Рейтинг: 0 / 0
25.02.2010, 10:57
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487459
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Кифирчикой... а с чего вы так решили?
Сами же и отвечаете на свой вопрос:
Кифирчикпришлось бы.... ну и?
а... кажется понял, это вы к тому, что если без хранимок, то вы только в одном "слое" внесли бы изменения, а тут надо и хранимку переделать, и в её вызове на клиенте добавить несколько параметров.. ну да... это очень сложноТо есть ваша готовая хранимка обеспечить нормальное управление транзакциями не позволяет. Придется писать другую. О чем и речь. А то за главное преимущество хранимок выдавалась простота внесения изменений. Оказывается простота заключается в написании новой хранимки почти на каждый чих.

КифирчикBogdanov AndreyНо задач, которые бы не решались без них - нет.
... в смысле вам не попадалисьА вам попадались? Пример приведете? А я просто весь текст вашей хранимки на язык СП перепишу и хранимку выкину. Работать перестанет?
...
Рейтинг: 0 / 0
25.02.2010, 11:11
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487479
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
iscrafmdrev
Я ответил на Ваш вопрос?
Вы описали обычные процедуры бизнес-логики. К проверке ввода не имеющие отношения. Все действия действительно выполняются на сервере, ну разве что, применительно к банкомату, проверка максимальной суммы атомарной транзакции, заданной как параметр. Для остального - связь с сервером.

drevПравило второе: "Сумма снятия не должна превышать остаток на счету более чем на предел овердрафта, установленный для данного пользователя".
Опять же, предварительную проверку можно провести на клиенте, но окончательная должна быть обеспечена на уровне БД.
какие еще предварительные проверки овердрафта на клиенте? шутить изволите.

У нас с Вами явно разные представления о data validation.

Попытка противопоставить "проверку ввода и процедуры бизнес-логики" ясно это показывает.

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

Вы согласны с этим? Если "да" - я не понимаю смысла Вашего высказывания. Если "нет" - не могли бы вы привести свое определение?

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

После проверки пин-кода на клиенте(банкомате) доступна информация об текущем остатке (если есть овердрафт, и о нем тоже). Эту информацию можно использовать для предварительной проверки валидности транзакции и подсказки клиенту, что она может быть невалидной.

Так понятно?
...
Рейтинг: 0 / 0
25.02.2010, 11:24
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487495
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
drevУ нас с Вами явно разные представления о data validation.
Попытка противопоставить "проверку ввода и процедуры бизнес-логики" ясно это показывает.

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

drevНапример - "проверки овердрафта на клиенте".
После проверки пин-кода на клиенте(банкомате) доступна информация об текущем остатке (если есть овердрафт, и о нем тоже). Эту информацию можно использовать для предварительной проверки валидности транзакции и подсказки клиенту, что она может быть невалидной.
Так понятно?
в каком банке таким образом банкоматы построены? постараюсь не пользоваться
...
Рейтинг: 0 / 0
25.02.2010, 11:31
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487509
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
iscrafmКифирчикiscrafm как же все-таки поступят адепты утверждения "все только на хранимках"?
рискну предположить, что напишут очередную ХП для этого действия, и возможно, если будет изменяемое колличество параметров, внутри будет динамичекский SQL

а количество параметров тоже динамически изменяемое? Или парсер напишут?


Ну, если пошла такая пьянка :) А парсер-то зачем писать? Передали XML и пользуемся встроенным :)
...
Рейтинг: 0 / 0
25.02.2010, 11:37
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487552
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
iscrafm drevУ нас с Вами явно разные представления о data validation.
Попытка противопоставить "проверку ввода и процедуры бизнес-логики" ясно это показывает.

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

Вау, чем дальше в лес.. ОК, читаем здесь : http://msdn.microsoft.com/en-us/library/aa291820(VS.71).aspx
1. "One of the simplest forms of data validation is verifying the data type."
2. "This kind of complex multifile data validation is often best handled with procedure-based business rules."

Так понятно?
iscrafm
drevНапример - "проверки овердрафта на клиенте".
После проверки пин-кода на клиенте(банкомате) доступна информация об текущем остатке (если есть овердрафт, и о нем тоже). Эту информацию можно использовать для предварительной проверки валидности транзакции и подсказки клиенту, что она может быть невалидной.
Так понятно?
в каком банке таким образом банкоматы построены? постараюсь не пользоваться
Я боюсь, Вас туда клиентом не возьмут :( Wells Fargo, например.
...
Рейтинг: 0 / 0
25.02.2010, 11:58
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487570
Кифирчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кифирчик
Участник
iscrafm...а количество параметров тоже динамически изменяемое? Или парсер напишут?...
...подразумевается то, что и написано. пройтись по записям выборки и вызвать для каждой UPDATE-процедуру...
что-то редко попадались
если очень интересно, приведите более осязаемый пример... табличку, условия
и пример кода, в котором бы вы это выполнили из СП

А вам попадались? Пример приведете? А я просто весь текст вашей хранимки на язык СП перепишу и хранимку выкину. Работать перестанет?
конкретно та, что я привел, наверно будет, я именное её выбрал, потому, что она самая коротка...
скажите как вы в СП будете разруливать ситуацию:
связанные сущности: адрес-клиент-счет
допустим, запускается с сервера приложений, некоторая процедура, которая должна рассчитать списание клиентам за услуги... клиентов - большой список... время выполнения, на СП... ну допустим 3 минуты...
сумма списанией за услуги рассчитывается исходя из адреса клиента...
запускается, ваша процедура на СП (А).... и, в эти 3 минуты, один из менеджеров, вносит изменение в базу, меняет одному из клиентов адрес, либо вообще закрывает "счет"(В)...
И так сходятся звезды, и погода на марсе

1. А - начата обработка
...
2. В - проверка что сальдо не меньше нуля
3. А - доходим до этого клиента, считываем о нем данные, на основании которых делаем списание
4. А - рассчитываем на основании адреса сумму списания
5. В - закрытие счета (либо изменение адреса, а то есть условий начисления)
6. А - списание со со счета (сумма уже не корректная, либо записана на закрытый счет)

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

более того, может возникнуть ситуация (к примеру), когда А, заблокировало одни ресурсы (Х), Б другие(Y)...
потом А пытается добраться до Y, и замирает, потому, что Y заблокировано процессом В,
а Б ждет когда освободится X, потому, что X заблок процессом A...
И в лучшем случае, и A и В отвалятся с ошибками
...
Рейтинг: 0 / 0
25.02.2010, 12:05
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487601
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
dreviscrafm drevУ нас с Вами явно разные представления о data validation.
Попытка противопоставить "проверку ввода и процедуры бизнес-логики" ясно это показывает.

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

Вау, чем дальше в лес.. ОК, читаем здесь : http://msdn.microsoft.com/en-us/library/aa291820(VS.71).aspx
1. "One of the simplest forms of data validation is verifying the data type."
2. "This kind of complex multifile data validation is often best handled with procedure-based business rules."

Так понятно?

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

drev
iscrafm
drevНапример - "проверки овердрафта на клиенте".
После проверки пин-кода на клиенте(банкомате) доступна информация об текущем остатке (если есть овердрафт, и о нем тоже). Эту информацию можно использовать для предварительной проверки валидности транзакции и подсказки клиенту, что она может быть невалидной.
Так понятно?
в каком банке таким образом банкоматы построены? постараюсь не пользоваться
Я боюсь, Вас туда клиентом не возьмут :( Wells Fargo, например.
спасибо за подсказку. Я же и говорю, что не хочу пользоваться банкоматами, в которые без моего ведома доступный остаток счета отправляется, типа для верификации правильности введенных сумм. Не одну тысячу долларов уже "тырили".
...
Рейтинг: 0 / 0
25.02.2010, 12:18
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487622
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Кифирчикiscrafm...а количество параметров тоже динамически изменяемое? Или парсер напишут?...
...подразумевается то, что и написано. пройтись по записям выборки и вызвать для каждой UPDATE-процедуру...
что-то редко попадались
если очень интересно, приведите более осязаемый пример... табличку, условия
и пример кода, в котором бы вы это выполнили из СП

да можно взять самый банальный пример. В товарах по заданному условию заменить значение категории товара.
...
Рейтинг: 0 / 0
25.02.2010, 12:26
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487704
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
iscrafmdreviscrafm drevУ нас с Вами явно разные представления о data validation.
Попытка противопоставить "проверку ввода и процедуры бизнес-логики" ясно это показывает.

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

Вау, чем дальше в лес.. ОК, читаем здесь : http://msdn.microsoft.com/en-us/library/aa291820(VS.71).aspx
1. "One of the simplest forms of data validation is verifying the data type."
2. "This kind of complex multifile data validation is often best handled with procedure-based business rules."

Так понятно?

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




Я-то понял:)

Может Вы не будете "лезть с ножом на паровоз"? (с) Макаренко.

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

Из его использование вытекает, что понятие "верификация" не пересекается с понятием "валидация".

Что противоречит высказыванию " простейшей формой валидации является верификация .."


Далее, Вы согласны наконец, что "процедур бизнес-логики" все-таки имеют отношение к "валидации"? Великолепно :)
...
Рейтинг: 0 / 0
25.02.2010, 12:53
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487713
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Кифирчикразместив это в хранимой процедуре и залочив нужные таблицы,А что мешает "залочить нужные таблицы", разместив код в СП? :)
...
Рейтинг: 0 / 0
25.02.2010, 12:56
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487765
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
drevВ фразах "Верификацию действительно делают на клиенте. Валидацию тоже конечно можно, если система для монопольного использования." - ключевое слово - "тоже".
Из его использование вытекает, что понятие "верификация" не пересекается с понятием "валидация".
Что противоречит высказыванию " простейшей формой валидации является верификация .."

верификация=проверка
валидация=проверка+утверждение
что с чем вступает в противоречие - непонятно. Валидацию действительно можно сделать на клиенте, если работать в режиме монопольного доступа. Вы о чем собственно? Особенно про нижи и паровозы...
...
Рейтинг: 0 / 0
25.02.2010, 13:11
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487779
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
drev
Далее, Вы согласны наконец, что "процедур бизнес-логики" все-таки имеют отношение к "валидации"?
"согласен наконец-то" говорят когда с чем-то был не согласен, а потом согласился. Естественно процедуры бизнес-логики имеют отношение к валидации. Именно с их помощью выполняется авторизация платежных транзакций, резервирование билетов, списание товара со склада и т.п.
...
Рейтинг: 0 / 0
25.02.2010, 13:15
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487791
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
iscrafmdrevВ фразах "Верификацию действительно делают на клиенте. Валидацию тоже конечно можно, если система для монопольного использования." - ключевое слово - "тоже".
Из его использование вытекает, что понятие "верификация" не пересекается с понятием "валидация".
Что противоречит высказыванию " простейшей формой валидации является верификация .."

верификация=проверка
валидация=проверка+утверждение
что с чем вступает в противоречие - непонятно. Валидацию действительно можно сделать на клиенте, если работать в режиме монопольного доступа. Вы о чем собственно? Особенно про нижи и паровозы...
Ок, проверка, что значение входит в границы диапазона, это валидация или верификация?
...
Рейтинг: 0 / 0
25.02.2010, 13:21
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487804
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
drevпроверка, что значение входит в границы диапазона, это валидация или верификация?
верификация
...
Рейтинг: 0 / 0
25.02.2010, 13:26
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487805
Кифирчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кифирчик
Участник
iscrafmда можно взять самый банальный пример. В товарах по заданному условию заменить значение категории товара.
ну... я думал вы покажете сложное условие с переменным колличеством параметров

Bogdanov AndreyА что мешает "залочить нужные таблицы", разместив код в СП? :)
ух... действительно... лочить из клиента, с хинтами...
покажите пример, перепишите на СП ту процедуру, которую я привел в пример... хотябы примерно.. на знакомо вам языке
мне правда очень интересно
...
Рейтинг: 0 / 0
25.02.2010, 13:27
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487812
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Кифирчикiscrafmда можно взять самый банальный пример. В товарах по заданному условию заменить значение категории товара.
ну... я думал вы покажете сложное условие с переменным колличеством параметров

зачем? достаточно банального
...
Рейтинг: 0 / 0
25.02.2010, 13:30
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487830
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
iscrafmdrevпроверка, что значение входит в границы диапазона , это валидация или верификация?
верификация

There are several types of data validation .

•Data type validation.
• Range checking .
•Code checking.
•Complex validation.

http://msdn.microsoft.com/en-us/library/aa291820(VS.71).aspx

Вы согласны?
...
Рейтинг: 0 / 0
25.02.2010, 13:37
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487892
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
dreviscrafmdrevпроверка, что значение входит в границы диапазона , это валидация или верификация?
верификация

There are several types of data validation .

•Data type validation.
• Range checking .
•Code checking.
•Complex validation.

http://msdn.microsoft.com/en-us/library/aa291820(VS.71).aspx

Вы согласны?
без привязки к контексту - вполне.
...
Рейтинг: 0 / 0
25.02.2010, 13:55
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487903
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
...и тут мне вспомнился фон-нейман, в частности его 3й принцип .
Код: plaintext
1.
2.
------------------------------
!Напрасный труд хуже пьянства!
------------------------------
...
Рейтинг: 0 / 0
25.02.2010, 14:00
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487918
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
drev, многие путают эти понятия.
у них даже определения, в том же ISO практически одинаковые. Несколько "но"...
1. верификация всегда выполняется до валидации, ни никак не наоборот
2. если верификация говорит, что да, данные соответствуют, то валидация подтверждает результаты верификации... утверждает, фиксирует.. как больше нравится, смысл от этого не меняется.
если, допустим, на клиенте выполняется верификация правильности исходных данных для транзакции (проверка на соответствие заданным ограничениям), то процедура валидации, выполнив транзакцию и доказав тем самым их правильность, подтверждает это. Слово "доказав" - ключевое для понимания различий в этих двух терминах.
...
Рейтинг: 0 / 0
25.02.2010, 14:05
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487971
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Кифирчикух... действительно... лочить из клиента, с хинтами...
покажите пример, перепишите на СП ту процедуру, которую я привел в пример... хотябы примерно.. на знакомо вам языке
мне правда очень интересноНу учитывая то, что смысл половины выполняемых вами в этой процедуре действий мне вообще не понятен. Зачем делается блокировка двух таблиц я понять не смог, уровень изоляциив serialazable для такой тривиальной задачи мне бы и в страшном сне не приснился. Ну а загадочные манипуляции с ERROR_NUMBER... Возможно тут специфика MSSQL. Я попытаюсь вкратце описать понятный мне смысл: задача процедуры - вставить запись в таблицу избежав появления дубликатов. При этом выполняется фиксация транзакции. Есть еще манипуляции с логгированием, но это вообще в стандартном обработчике исключений должно быть и к вставке записей в конкретную таблицу относиться не должно.
Если задача действительно такова, то для ее выполнения в Oracle я бы просто повесил unique на таблицу и сделал простой инсерт обрамив его try-catch блоком для того, чтобы отформатировать сообщение об ошибке.
На Java это будет выглядеть примерно так (ни компилировать, ни выполнять не пытался)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
try{
   call = connection.prepareCall('insert into a_flat_list(street_id, build_num, build_char, room_num, room_char)
        values(?,?,?,?,?) returning flat_id into :1');
   call.setInt( 1 ,street_id);
   if(build_num== 0 ) call.setNull( 2 ,build_num);
   else call.setInt( 2 ,build_num);
   call.setString( 3 ,build_char);
   if(room_num== 0 ) call.setNull( 4 );
   else call.setInt( 4 ,room_num);
   call.setString( 5 ,room_char);
   call.registerOutParameter( 1 , OracleTypes.NUMBER );
   call.execute();
   flat_id = call.getInt( 1 );
   connection.commit();
}catch (Exception e){
   connection.rollback();
   err_msg = e.getText();
}
Надо сказать, что вызов вашей процедуры будет выглядеть точно также :)
...
Рейтинг: 0 / 0
25.02.2010, 14:18
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487973
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
можно на примере любой системы резервирования билета на авиарейс посмотреть (несколько лет уже не пользуюсь услугами билетных касс для этой цели). Первым делом выполняется верификация данных для транзакции резервирования. Проверяются пункты отправления и назначения, доступность выбранного рейса на требуюмую дату, наличии мест выбранного класса (предварительно на момент запроса, естественно) и т.д. и т.п. Для этого на "клиента" подтягивается вся необходимая информация. После подтверждения оплаты выполняется окончательная валидация и резервирование, клиент получает доказательство того, что место в салоне зарезервированно, в виде электронного билета.
...
Рейтинг: 0 / 0
25.02.2010, 14:19
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36487978
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
сорри за опечатки
...
Рейтинг: 0 / 0
25.02.2010, 14:21
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36488102
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
Bogdanov AndreyВозможно тут специфика MSSQL. Я попытаюсь вкратце описать понятный мне смысл: задача процедуры - вставить запись в таблицу избежав появления дубликатов. При этом выполняется фиксация транзакции. Есть еще манипуляции с логгированием, но это вообще в стандартном обработчике исключений должно быть и к вставке записей в конкретную таблицу относиться не должно.
Если задача действительно такова, то для ее выполнения в Oracle я бы просто повесил unique на таблицу и сделал простой инсерт обрамив его try-catch блоком для того, чтобы отформатировать сообщение об ошибке.Нет здесь никакой специфики MSSQL, только специфика девелопера.
...
Рейтинг: 0 / 0
25.02.2010, 14:59
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36488420
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
ChAНет здесь никакой специфики MSSQL, только специфика девелопера.Я это подозревал, но не был на 100% уверен.
...
Рейтинг: 0 / 0
25.02.2010, 16:36
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36488452
Кифирчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кифирчик
Участник
Bogdanov AndreyНу учитывая то, что смысл половины выполняемых вами в этой процедуре действий мне вообще не понятен. Зачем делается блокировка двух таблиц я понять не смог, уровень изоляциив serialazable для такой тривиальной задачи мне бы и в страшном сне не приснился. Ну а загадочные манипуляции с ERROR_NUMBER... Возможно тут специфика MSSQL
с уровнем изоляции, наверно и в правдо "жесковато", и именно для одно инсерта это лишнее, а все остальное придумал не я
http://msdn.microsoft.com/ru-ru/library/ms179296(SQL.90).aspx
примерно по середине страницы
Следующие сценарии кода для сеанса 1 и сеанса 2 выполняются одновременно....
...
Ошибка жертвы взаимоблокировки приведет к тому, что управление внезапно будет передано блоку CATCH и транзакция перейдет в нефиксируемое состояние. Внутри блока CATCH жертва взаимоблокировки может выполнить откат транзакции и вновь пытаться обновить таблицу до тех пор, пока процесс обновления не завершится успешно или пока не будет исчерпан лимит попыток. К прекращению попыток обновления таблицы приведет то из перечисленных событий, которое наступит первым.

меня по правде и интерисовало каким образом вы реализуете что написано выше, а не параметризированный запрос. Хотя, познавательно.
...
Рейтинг: 0 / 0
25.02.2010, 16:47
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36488518
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
Bogdanov AndreyChAНет здесь никакой специфики MSSQL, только специфика девелопера.Я это подозревал, но не был на 100% уверен.Да за одно это
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
if @build_num =  0  set @build_num = null;
if @room_num  = 0   set @room_num  = null;

-- проверит что квартиры с такими буквами и номерами нет в базе
SELECT @flat_id = a.flat_id
FROM dbo.a_flat_list a
WHERE a.street_id  = @street_id
AND   a.build_num  = @build_num
AND   a.build_char = @build_char
AND   a.room_num   = @room_num
AND   a.room_char  = @room_char;
надо увольнять без выходного пособия.
...
Рейтинг: 0 / 0
25.02.2010, 17:14
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36488603
web_fox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
web_fox
Участник
ChABogdanov AndreyChAНет здесь никакой специфики MSSQL, только специфика девелопера.Я это подозревал, но не был на 100% уверен.Да за одно это
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
if @build_num =  0  set @build_num = null;
if @room_num  = 0   set @room_num  = null;

-- проверит что квартиры с такими буквами и номерами нет в базе
SELECT @flat_id = a.flat_id
FROM dbo.a_flat_list a
WHERE a.street_id  = @street_id
AND   a.build_num  = @build_num
AND   a.build_char = @build_char
AND   a.room_num   = @room_num
AND   a.room_char  = @room_char;
надо увольнять без выходного пособия.

ChA,

ваш поступок низок. В теме обсуждают "Где должна лежать бизнес-логика в мнгоуровневом приложении".
...
Рейтинг: 0 / 0
25.02.2010, 17:41
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36488615
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
web_fox
ChA,

ваш поступок низок. В теме обсуждают "Где должна лежать бизнес-логика в мнгоуровневом приложении".
web_foxВижу, что вы не понимаете этих вещей просто по неопытности. Это не в обиду, но вопросы выглядят просто незрелыми, да ещё с оттенком задаваки[/quot]
...
Рейтинг: 0 / 0
25.02.2010, 17:46
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36488635
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
web_foxChA,
ваш поступок низок. В теме обсуждают "Где должна лежать бизнес-логика в мнгоуровневом приложении".
web_fox
во, видно опытного человека.
web_fox, Вас задело то, что человека, которого вы при виде приведенного выше текста назвали опытным, кто-то посмел немного покритиковать?
...
Рейтинг: 0 / 0
25.02.2010, 17:54
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36488885
Кифирчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кифирчик
Участник
ChA, ну вы хоть объясните что там такого страшного, ни как не пойму ваших загадочных намеков.
нули в null превратил? так мне в дальнейшем удобнее, либо цифры(не нули), либо null
очень обидело когда я не правильно мантру про блокировки сказал?
каюсь, так и не выловил кто кого лочит, и решил чтоб наверняка, все операции обернул в TRY, уровень SERIALIZABLE и WITH(TABLOCK) всех "зависимых" таблиц
что ещё? вы там кстати ещё одну ошибку не заметили

эх, рано ещё мне к вам в падаваны, недорос... пойду учить мантры

iscrafm...кто-то посмел немного покритиковать...
давайте давайте...

кто что ещё хочет сказать по поводу моей специфики... в смысле квалификации? )))
...
Рейтинг: 0 / 0
25.02.2010, 20:14
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36488886
ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКС
Гость
iscrafm
Верификацию действительно делают на клиенте. Валидацию тоже конечно можно, если система для монопольного использования.

Очень, очень красивое решение - валидация на клиенте.
Вам бы банковское ПО проектировать.
...
Рейтинг: 0 / 0
25.02.2010, 20:15
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36488932
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Кифирчикменя по правде и интерисовало каким образом вы реализуете что написано выше, а не параметризированный запрос. Хотя, познавательно.Если на пальцах, то при вставке записи в таблицу имеющую уникальный индекс СУБД сама блокирует необходимые ветви индекса обеспечивая отсутствие дубликатов вне зависимости от числа одновременно работающих пользователей. Если несколько сессий одновременно попытаются вставить одно и то же значение, то вторая из них повиснет на блокировке вплоть до завершения транзакции в первой. А после commit или rollback в первой выдаст либо сообщение о нарушении уникальности, либо позволит вставить. Если же разные сессии вставляют непротиворечащие друг другу записи, то никаких ожиданий не будет.
Если же речь о взаимной блокировке (deadlock), то тут несколько сложнее, но и возникает такая блокировка нечасто (и решается обычно не специальной ручной блокировкой чего-то, а более аккуратным отношением к последовательности выполнения операторов), а уж при вставке единственной записи внутри транзакции получить такое и вовсе невозможно. Но ликбез по deadlock я проводить не буду - это в рамки одного поста вряд ли влезет. Написанное к Oracle относится, но думаю, что и в других СУБД поведение похоже.

КифирчикChA, ну вы хоть объясните что там такого страшного, ни как не пойму ваших загадочных намеков.
нули в null превратил? так мне в дальнейшем удобнее, либо цифры(не нули), либо null
Страшно, то что вы производите сравнение с null-значением и, видимо, даже не подозреваете о подводных камнях встречающихся при этом.
...
Рейтинг: 0 / 0
25.02.2010, 20:55
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36488949
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
ОКСiscrafm
Верификацию действительно делают на клиенте. Валидацию тоже конечно можно, если система для монопольного использования.

Очень, очень красивое решение - валидация на клиенте.
Вам бы банковское ПО проектировать.
а что, банковское ПО стало однопользовательское? Не встречал. Поделитесь ссылкой?
...
Рейтинг: 0 / 0
25.02.2010, 21:02
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36488955
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
ОКСiscrafm
Верификацию действительно делают на клиенте. Валидацию тоже конечно можно, если система для монопольного использования.
Очень, очень красивое решение - валидация на клиенте.
Вам бы банковское ПО проектировать.
хотя подумал и нашел объяснение. Похоже просто загадочный ОКС не совсем понимает о чем говорит. Другого объяснения не получается.
...
Рейтинг: 0 / 0
25.02.2010, 21:07
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36488957
ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКС
Гость
iscrafm[quot ОКС][quot iscrafm]
а что, банковское ПО стало однопользовательское? Не встречал. Поделитесь ссылкой?

Считаю, что проектировщик, который выносит валидацию на сторону клиента с таким же успехом справится и с банковским ПО.
...
Рейтинг: 0 / 0
25.02.2010, 21:09
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36488959
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
ОКСiscrafm[quot ОКС][quot iscrafm]
а что, банковское ПО стало однопользовательское? Не встречал. Поделитесь ссылкой?

Считаю, что проектировщик, который выносит валидацию на сторону клиента с таким же успехом справится и с банковским ПО.
и я так считаю. Вроде по-русски написано. Или загадочный ОКС не совсем понимает по-русски?
...
Рейтинг: 0 / 0
25.02.2010, 21:11
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36488963
ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКС
Гость
iscrafmхотя подумал и нашел объяснение.

Это хороший, годный метод.
Не стесняйтесь его использовать.
...
Рейтинг: 0 / 0
25.02.2010, 21:12
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36488966
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
ОКС,

что сказать то хотели?
...
Рейтинг: 0 / 0
25.02.2010, 21:14
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36488970
ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКС
Гость
iscrafm,

Смысл какого именно слова вам объяснить?
...
Рейтинг: 0 / 0
25.02.2010, 21:18
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36488987
ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКС
Гость
Кифирчик
кто что ещё хочет сказать по поводу моей специфики... в смысле квалификации? )))

Скорее всего, они имеют в виду, что условие a.build_num = null никогда не выполнится.
...
Рейтинг: 0 / 0
25.02.2010, 21:32
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36488991
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
ОКСiscrafm,

Смысл какого именно слова вам объяснить?
да начиная с самого первого перла
ОКСiscrafm
Верификацию действительно делают на клиенте. Валидацию тоже конечно можно, если система для монопольного использования.

Очень, очень красивое решение - валидация на клиенте.
Вам бы банковское ПО проектировать.


p.s. какой-то бестолковый тролль попался, ничего не понимает
...
Рейтинг: 0 / 0
25.02.2010, 21:34
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36489038
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
iscrafmdrev, многие путают эти понятия.
у них даже определения, в том же ISO практически одинаковые. Несколько "но"...
1. верификация всегда выполняется до валидации, ни никак не наоборот
2. если верификация говорит, что да, данные соответствуют, то валидация подтверждает результаты верификации... утверждает, фиксирует.. как больше нравится, смысл от этого не меняется.
если, допустим, на клиенте выполняется верификация правильности исходных данных для транзакции (проверка на соответствие заданным ограничениям), то процедура валидации, выполнив транзакцию и доказав тем самым их правильность, подтверждает это. Слово "доказав" - ключевое для понимания различий в этих двух терминах.

Ладно, Б-г с ними, с терминами.. чувствую, что прояснить до конца не получится

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

Например, проверка на максимальную сумму снятия может быть простой (для всех < $500) или зависеть от типа пользователя (или даже от конкретного пользователя ).

Таким образом мы приходим к необходимости частичного или полного дублирования бизнес логики как минимум в БД и на клиенте.

В чрезвычайно редких случаях ее также нужно имплементировать на МТ, который, кстати, вовсе не обязательно СП.
...
Рейтинг: 0 / 0
25.02.2010, 22:24
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36489496
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
drevТаким образом мы приходим к необходимости частичного или полного дублирования бизнес логики как минимум в БД и на клиенте.
Почему дублировать? Клиент может кешировать вместе с данными и те бизнес-правила, которые необходимы для проверки этих данных :) Зависит от конкретной реализации клиентской части, не более.
...
Рейтинг: 0 / 0
26.02.2010, 10:36
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36489781
web_fox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
web_fox
Участник
Bogdanov Andrey,

Bogdanov AndreyЯ правильно понимаю, что обяснить сделай "insert into..." существенно сложнее, чем вызови процедуру "insertInto". Неужели все так плохо с разработчиками среднего слоя?

Неудачный минимализм.
Если вам не нравится идея - это не повод приводить глупые примеры. Процедур "insertInto" не бывает, бывают "CreateClient", "CreateWorkOrder" и т.п. "Сегодня" в них может оказаться и один инсерт, а "завтра" не только. А ещё у нас разработчики среднего слоя не только не делают "инсерты" и не проектируют БД , но и не проектируют интерфейс пользователя - это тоже делают отдельные люди, хотя и большинству разработчиков не составит труда никидать формочку и без UI-дизайнера, но не делают, потому что не специалисты в этом и они не будут сидеть и просчитывать, например, число действий пользователя для выполнения сценария в системе.

Идею я объяснил - распредление работ в соответствии с профессиональными навыками. Мы не расчитываем на Java-программистов, которые спокойно могут сертифицироваться на разработчика под Oracle. Мы задачи распределяем по-другому. И я не называю ваш подход "костылями", программируйте на здоровье.
...
Рейтинг: 0 / 0
26.02.2010, 12:01
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36489850
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
разработчик среднего слоя
1. не знает структуру БД
2. не занимается бизнес-логикой, т.к. сказано, что вся логика на процедурах БД
3. не занимается клиентской частью и интерфейсом
Загадка: чем занимается разработчик среднего слоя в таком случае? Все что осталось - ретрансляция запросов от клиента к СУБД. Эта задача один раз проектируется, кодируется и забывается. К тому же, полно таких ретрансляторов в готовом виде. Может о чем-то умалчивается? Или просто нет информации о том, кто и чем занимается?
...
Рейтинг: 0 / 0
26.02.2010, 12:25
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36489856
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
web_foxЕсли вам не нравится идея - это не повод приводить глупые примеры. Процедур "insertInto" не бывает, бывают "CreateClient", "CreateWorkOrder" и т.п. Правда не бывает? Во всех встречавшихся мне примерах реализации вашего подхода "вся работа с БД только через ХП" как раз процедуры insertInto (а также updateInto и т.п.) встречались в изобилии. Да и Кифирчик именно такую процедуру приводил.
Ну если вы так не делаете, то ваш подход в целом понятен, правда средства его реализации на мой взгляд не лучшие. РСУБД позволяет организовать данные в соответствии с реляционной моделью. Наиболее естественным и удобным языком для работы с реляционными данными является SQL. Вы поверх реляционной модели строите объектную - именно в рамках этой модели появляются такие объекты, как Client, WorkOrder и т.п. Согласен, для реализации бизнес-логики объектная модель данных действительно удобнее (то есть имеем не два слоя "модель данных"-"бизнес-логика", а три "реляционная модель"-"объектная модель"-"бизнес логика"). Но вот ее реализация средствами хранимых процедур в РСУБД не самый удобный вариант. Гораздо удобнее вынести слой преобразования реляционной модели в объектную на более подходящие для этого средства. Может быть и вообще стоит отказаться от слоя реляционной модели (зачем она вам?), а использовать ООБД.
Теперь можно вернуться в основное русло темы немного расширив его и к вопросу "где должна лежать бизнес-логика?" добавить еще и вопрос "где должна лежать объектная модель данных?" :)
...
Рейтинг: 0 / 0
26.02.2010, 12:28
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36489944
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Bogdanov Andreyможно вернуться в основное русло темы немного расширив его и к вопросу "где должна лежать бизнес-логика?" добавить еще и вопрос "где должна лежать объектная модель данных?"
все движется к этому
...
Рейтинг: 0 / 0
26.02.2010, 13:01
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36489969
ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКС
Гость
iscrafm

Ничего, наберетесь опыта и сами поймете, почему ваше решение размещать валидацию на клиенте выглядит смешным и по-студенчески наивным.
...
Рейтинг: 0 / 0
26.02.2010, 13:10
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36489987
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
ОКСiscrafm

Ничего, наберетесь опыта и сами поймете, почему ваше решение размещать валидацию на клиенте выглядит смешным и по-студенчески наивным.
у меня нет таких решений? Ты меня наверное с кем-то перепутал. Какой-то бестолковый тролль.
Костя отвечай уже под своим ником.
...
Рейтинг: 0 / 0
26.02.2010, 13:16
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36490011
ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКС
Гость
Ну нет, так нет.
Тогда вам лучше пояснить, что это была шутка:

iscrafm
Верификацию действительно делают на клиенте. Валидацию тоже конечно можно, если система для монопольного использования.

А то кто-нибудь может воспринять, как хорошую идею.
Некрасиво может получиться.
...
Рейтинг: 0 / 0
26.02.2010, 13:24
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36490045
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
ОКСНу нет, так нет.
Тогда вам лучше пояснить, что это была шутка:

iscrafm
Верификацию действительно делают на клиенте. Валидацию тоже конечно можно, если система для монопольного использования.

А то кто-нибудь может воспринять, как хорошую идею.
Некрасиво может получиться.
нет, это была не шутка. Там по-русски все написано. Скажи на какой язык перевести, я переведу смысл фразы " если система для монопольного использования ", если по-русски не понимаешь. Могу помочь. Странно, что ты с незнанием русского языка взялся флудить на русскоязычном форуме.
...
Рейтинг: 0 / 0
26.02.2010, 13:36
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36490254
ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКС
Гость
iscrafmнет, это была не шутка. Там по-русски все написано. Скажи на какой язык перевести, я переведу смысл фразы " если система для монопольного использования ", если по-русски не понимаешь. Могу помочь. Странно, что ты с незнанием русского языка взялся флудить на русскоязычном форуме.

Есть какие-нибудь мысли по обоснованности данного решения или ваши слова следует воспринимать как "личное мнение, не основанное на сравнении и анализе"?
...
Рейтинг: 0 / 0
26.02.2010, 14:42
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36490262
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
ОКСiscrafmнет, это была не шутка. Там по-русски все написано. Скажи на какой язык перевести, я переведу смысл фразы " если система для монопольного использования ", если по-русски не понимаешь. Могу помочь. Странно, что ты с незнанием русского языка взялся флудить на русскоязычном форуме.

Есть какие-нибудь мысли по обоснованности данного решения или ваши слова следует воспринимать как "личное мнение, не основанное на сравнении и анализе"?
мнение о чем?
...
Рейтинг: 0 / 0
26.02.2010, 14:43
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36490269
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
о том, что в однопользовательской системе без разницы, где делать проверку? Или о том, что если человек не понимает по-русски, то ему нужно помочь, перевести?
...
Рейтинг: 0 / 0
26.02.2010, 14:45
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36490282
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
если по первому варианту, то могу даже дополнить: в системе для одного пользователя даже сервер не нужен.
Если по второму, то хоть и говорят, что не нужно кормить троллей, но если бедолага не понимает простых вещей, то почему бы и не дать кроху хлеба
...
Рейтинг: 0 / 0
26.02.2010, 14:49
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36490392
ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКС
Гость
iscrafmв системе для одного пользователя даже сервер не нужен.

У вас необходимость использования сервера определяется исключительно количеством пользователей системы?
...
Рейтинг: 0 / 0
26.02.2010, 15:27
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36490404
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
ОКСiscrafmв системе для одного пользователя даже сервер не нужен.

У вас необходимость использования сервера определяется исключительно количеством пользователей системы?
нет, она определяется необходимостью. А у вас?
...
Рейтинг: 0 / 0
26.02.2010, 15:32
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36490420
ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКС
Гость
iscrafmнет, она определяется необходимостью. А у вас?

Вы как-то сами себе противоречите:
iscrafmв системе для одного пользователя даже сервер не нужен.
...
Рейтинг: 0 / 0
26.02.2010, 15:37
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36490429
ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКС
Гость
Разницу же между монопольным использованием системы и количеством пользователей системы предлагаю изучить самостоятельно.
...
Рейтинг: 0 / 0
26.02.2010, 15:42
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36490433
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
ОКСiscrafmнет, она определяется необходимостью. А у вас?

Вы как-то сами себе противоречите:
iscrafmв системе для одного пользователя даже сервер не нужен.
необходимость - это когда что-то нужно. Для одного пользователя в сервере нет необходимости. Может не возникнуть необходимости и для двух-трех и т.п., если они работают в монопольном режиме (извини за употребление незнакомых тебе слов).
...
Рейтинг: 0 / 0
26.02.2010, 15:43
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36490470
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
ОКСРазницу же между монопольным использованием системы и количеством пользователей системы предлагаю изучить самостоятельно.
если не понимаешь что это такое применительно к информационным системам, попробуй дома с DVD центром провести эксперимент. Посади несколько человек послушать музыку. Уровень громкости регулируй на DVD, чтобы он всех удовлетворил. Потом, в гнездо для наушников, воткни эти самые наушники и отрегулируй звук при помощи регулятора на них (на клиенте), так чтобы было комфортно тебе. Поверь, барабанные перепонки остальных от этого не пострадают. Наслаждайся монопольным использованием звука. Можешь убрать сервер (центр), за ненадобностью, и воткнуть наушники в персональный плеер.
...
Рейтинг: 0 / 0
26.02.2010, 16:01
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36490523
ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКС
Гость
iscrafmДля одного пользователя в сервере нет необходимости.

Забавный максимализм.
Где же тогда хранить данные, скажем, той или иной мобильной системе сбора данных, системе видеорегистрации или хотя бы единственному бухгалтеру небольшой компании?
...
Рейтинг: 0 / 0
26.02.2010, 16:26
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36490530
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
ОКСiscrafmДля одного пользователя в сервере нет необходимости.

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

p.s. с нашниками получилось?
...
Рейтинг: 0 / 0
26.02.2010, 16:27
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36490568
ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКС
Гость
iscrafmp.s. с нашниками получилось?

Попробую на досуге.
Вы же в свою очередь пообещайте прочитать что-нибудь об использовании СУБД в монопольном режиме.
...
Рейтинг: 0 / 0
26.02.2010, 16:44
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36490592
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
ОКСiscrafmp.s. с нашниками получилось?

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

p.s. проблемы с пониманием текста по-русски выше уже обсуждались
...
Рейтинг: 0 / 0
26.02.2010, 16:51
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36490914
ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКС
Гость
Ну тогда не читайте. :)
...
Рейтинг: 0 / 0
26.02.2010, 18:37
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36491877
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
Подобъем предварительные итоги:

Размещение бизнес-логики на сервере приложений:

1. Независимость от типа СУБД

За редкими исключениями МИФ!
В качестве элементарного примера:
В общем-то синтаксис того же SQL отличен во всех базах, например, в MySQL:
SELECT DAYOFMONTH(MAX(post_date)) AS lastday,MONTH(MAX(post_date)) AS lastmonth ...
В Oracle:
SELECT TO_CHAR(MAX(post_date), 'DD') AS lastday, TO_CHAR(MAX(post_date), 'MM') AS lastmonth
Вместо функции NOW() или CURTIME(), Oracle имеет SYSDATE

В отличие от Mysql, где можно использовать:
INSERT INTO mytable SET mycolumn=myvalue
в Oracle INSERT процедура происходит только в формате
INSERT INTO mytable (ID,mycolumn) VALUES (1,"myvalue")
Возможно проблема с форматами данных типа date.
to_date('2008-08-13','yyyy-mm-dd');

И это я не затронул даже 100 части подводных камней.

2. Независимость от DBA
Отчасти достижима, т.к. если все писать максимально однотипно и не использовать большую часть функционала, включая и базовый, ни одной из СУБД, то можно обойтись самыми примитивными познаниями и лишь изредка привлекать специалистов со стороны.
Плата за это – приложение требующее в десятки, а то и в тысячи раз больше ресурсов. Это можно сравнить с желанием использовать кирпич и для строительства, и для забивания гвоздей, и для чесания спины, и убийства мух и в качестве доски для рисования. Кому не нравится сравнение с кирпичом, могут подставить сюда синхрофазатрон.
Результат соответствующий.
Еще один вариант, заставить разработчиков самим приобрести знания DBA – но тогда о какой независимости идет речь?

3. Одно место хранения бизнес-логики облегчает изменение и тестирование оной.
Отчасти верно, но:
- во-первых, обычно часть этой самой логики все равно ложится/дублируется на клиенте и СУБД, хотя бы в виде ограничений уникальности и foreign key.

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

Впрочем БЛ на СУБД здесь мало чем поможет. За одним НО - число приложений, умеющих работать с СУБД, на несколько порядков больше, чем с нашим сервером приложений.

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

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

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

Размещение бизнес-логики в СУБД:
- Если всей, то тут обсуждать нечего, IMHO это если и реализуемо, то разумным такой подход можно назвать только сильно не выспавшись.

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

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

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

- Выборку данных внешнее приложение должно осуществлять только через view.

- ХП должны предоставлять интерфейс уровня API операций, а не API таблицы, т.е. никаких insertIntoTableAppUsers, а только что-то типа addNewWebUser.

- Скорость смены технических средств работы с данными значительно меньше, чем скорость смены средств разработки, поэтому вероятность того, что нашей разработки придется переползать с какого-нибудь DBASE на Visual FoxPro, оттуда на .NET, а оттуда на JAVA, а оттуда на что-то еще, что гарантированно появится года через три, гораздо выше, чем вероятность смены СУБД.
А тогда, чем меньше было реализовано на среднем слое, тем проще будет выйти из ситуации.
Кстати, последнее соображение гораздо важней, чем многим кажется исходя из сегодняшней моды.


Хотя все вышеизложенное и не является серебряной пулей, но является разумным компромиссом.

Так?
...
Рейтинг: 0 / 0
27.02.2010, 12:24
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36491912
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
carper- Скорость смены технических средств работы с данными значительно меньше, чем скорость смены средств разработки, поэтому вероятность того, что нашей разработки придется переползать с какого-нибудь DBASE на Visual FoxPro, оттуда на .NET, а оттуда на JAVA, а оттуда на что-то еще, что гарантированно появится года через три, гораздо выше, чем вероятность смены СУБД.
А тогда, чем меньше было реализовано на среднем слое, тем проще будет выйти из ситуации.
Кстати, последнее соображение гораздо важней, чем многим кажется исходя из сегодняшней моды.


Хотя все вышеизложенное и не является серебряной пулей, но является разумным компромиссом.

Так?
если речь идет о домашних экспериментах, то так, Вы абсолютно правы. Я думал в топике речь идет о промышленных решениях
...
Рейтинг: 0 / 0
27.02.2010, 12:40
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36491991
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
iscrafm,
автор Я думал в топике речь идет о промышленных решениях

Вы правильно думали, именно о промышленных.

Я вам сейчас как заказчик говорю. Вот, может и не самый яркий, зато самый свежий пример, только вчера при выборе из двух систем ведения реестра акционеров (обе тысяч по 300 рублей, ага не больно-то серьезная сумма, но и не маленькая за коробочный, относительно простой, продукт) одна пролетела за свое пристрастие к FoxPro.
Если что, то вторая, выбранная, ничем не лучше и НЕ ХУЖЕ, отличие только в более современной программной платформе.
Да, может и глупый каприз, но, могу вас уверить, не единственный за неудовлетворение которых пролетают многие компьютерные компании и на гораздо большие суммы.

Вообще, со стороны заказчика бывает крайне интересно взглянуть на проблему, часто многое видится совсем иначе.
Многое, например, могу рассказать про то как выбираются крупные КИС (я не про откаты), но не в этом топике. :)
...
Рейтинг: 0 / 0
27.02.2010, 13:12
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36492081
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
carperЯ вам сейчас как заказчик говорю. Вот, может и не самый яркий, зато самый свежий пример, только вчера при выборе из двух систем ведения реестра акционеров (обе тысяч по 300 рублей, ага не больно-то серьезная сумма, но и не маленькая за коробочный, относительно простой, продукт) одна пролетела за свое пристрастие к FoxPro.
Если что, то вторая, выбранная, ничем не лучше и НЕ ХУЖЕ, отличие только в более современной программной платформе.

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

carper
Вообще, со стороны заказчика бывает крайне интересно взглянуть на проблему, часто многое видится совсем иначе.
Многое, например, могу рассказать про то как выбираются крупные КИС (я не про откаты), но не в этом топике. :)
может кому и будет интересно кстати.
...
Рейтинг: 0 / 0
27.02.2010, 13:44
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36492275
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
iscrafm,
"Не пойму правда как FoxPro соотносится со средствами для разработки серверов приложений, но это упустим."

Никак не относится, просто была иллюстрация того, что все не так просто сейчас с заказчиками.

Раз уж такой активности сейчас в топике нет, позволю себе большой offtop.

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

А ведь многие создатели таких программ так гордятся своей поддержкой зоопарка СУБД. :)

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

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

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


3. Выбор КИС, разумеется тянет кучу проблем, но тут уже объем затрат и рисков позволяет несколько изменить ограничения.

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

Зато критически важно, чтобы это было что-то из большой тройки, четверки, и чтобы специалисты по СУБД на рынке были не в теоретическом смысле.

Поддержка же одновременно разных СУБД малоинтересна.

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

Ну и архитектура такой системы уже тоже вещь весьма серьезная.

Это связано с тем, что КИС "под ключ", которую "настроили и работает" существует исключительно в мозгах маркетологов, и то только как один из инструментов развода лохов, в нормальной же системе до 30% функционала с годами оказывается вполне себе собственной разработки.


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

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

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

А вот уже упомянутые мной языки программирования, платформы и архитектура отнюдь не миф.

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

Вот и получается, что в реальной жизни попрыгунчики с СУБД на СУБД также редки как золотые медали наших на олимпиаде в Канаде, а смена архитектур и языков также часты как возвраты Аллы Борисовны на сцену. :)
...
Рейтинг: 0 / 0
27.02.2010, 15:09
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36492320
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
carper, спасибо за развернутый ответ, понятно.
Я лично, давно не занимаюсь именно тиражными системами. А когда создается индивидуальная система, то здесь поддержка различных СУБД очень даже помогает. Потому что, зачастую, то с какой СУБД должна работать система - выбор заказчика, и здесь поддержка "многобазности" не совсем миф, это реальная необходимость. "Попрыгунчики с СУБД на СУБД", как Вы выразились, действительно редкость. Поддержка в рамках одной системы нескольких СУБД совсем не редкость.
...
Рейтинг: 0 / 0
27.02.2010, 15:29
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36492493
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
iscrafm,
авторкогда создается индивидуальная система, то здесь поддержка различных СУБД очень даже помогает. Потому что, зачастую, то с какой СУБД должна работать система - выбор заказчика


C учетом того, что на "большую тройку" приходится 88% продаж СУБД (http://www.pcweek.ru/themes/detail.php?ID=119957), вероятность того, что заказчик начнет требовать что-то особенного, наверное, не окупится наваром с него.

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

Тут уже вопрос стоит только в том, как именно организовать эту поддержку - можно на 100% "накрыть" сервером приложений, вытягивая все остальное за счет железа. Если важно время, то иногда это единственный выход.

Хотя ..., вот я сейчас не поленился и составил небольшой список самых распостраненных СУБД:

СУБД Поддержка хранимых процедур
Oracle Да (PL/SQL, JAVA) Начиная с версии Oracle 10g поддерживается так называемая естественная компиляция (native compilation) хранимого процедурного кода в Си и затем в машинный код целевой машины, после чего при вызове хранимой процедуры происходит прямое выполнение её скомпилированного объектного кода.

DB2 Да (SQL/PL + написание хранимых процедур и функций на обычных языках программирования является традиционным способом, поддерживаемым с самого начала,)

Microsoft SQL Server Да (Transact-SQL + расширенные хранимыме процедуры на других языках программирования,например, на .Net, C++ или Delphi)
Informix Да
Ingres Да
InterBase Да (PSQL)
PostgreSQL Да (PL/pgSQL, PL/Tcl, PL/Perl, PL/Python)
Firebird Да (PSQL)

Т.е. получается, что если мы не впали в ересь, то у нас и так минимум процентов 80 бизнес-логики лежит на сервере приложений.

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

С учетом общей сложности системы, вклад БЛ на СУБД обычно составит процентов 5 от стоимости самой системы.

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

Тут, разумеется, возникает крайне неприятный вопрос - а на какие шиши все это хозяйство поддерживать?

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


Но это все были рассуждения отвлеченного порядка, далеко не уверен, что прав. :)
C этим мы работаем несколько иначе - чисто под себя полную систему никогда не заказываем, только изредка отдаем (отдавали, сейчас кризис замучил) на аутсорсинг отдельные модули.
...
Рейтинг: 0 / 0
27.02.2010, 16:39
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36492534
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
carperiscrafm,
авторкогда создается индивидуальная система, то здесь поддержка различных СУБД очень даже помогает. Потому что, зачастую, то с какой СУБД должна работать система - выбор заказчика


C учетом того, что на "большую тройку" приходится 88% продаж СУБД (http://www.pcweek.ru/themes/detail.php?ID=119957), вероятность того, что заказчик начнет требовать что-то особенного, наверное, не окупится наваром с него.
Хотя, нет, тут точно не скажу, наверное, есть такие, что придется ради них срочно затачивать систему подо что-то, что желают "их величества".

да ничего особенного, FireBird, PostgreSQL... Некоторые предъявляют требования типа такого: на том, что не потребует целый штат DBA. Все зависит от заказчика.
Далее Вы говорите о тиражировании системы по разные СУБД. Я же этот вариант не рассматриваю, поэтому комментировать не буду. Единственное замечу по поводу "Зато ХП запросто можно отдавать на аутсорсинг": такие варианты действительно бывали, когда на одном из предприятий холдинга захотели "настойчиво" другую СУБД. Дешевле отдать на аутсорсинг. Но, опять же, я рассматриваю только "свой" случай, когда нет необходимости одну и туже бизнес-логику тиражировать на разные СУБД. Кстати по теме... фрагменты бизнес-логики выполняющие обработку данных в БД предпочитаю делать там же ( ___ ).
...
Рейтинг: 0 / 0
27.02.2010, 16:59
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36492574
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
iscrafm,

Ну, так я вроде как ничего против и не имею. :)

Так, озвучиваю некоторые соображения.

С 3-х "звенными" приложениями хочется все же понять, что тут от моды, а что имеет свое рациональное звено. Мне лично кажется, что 3-х звенка, реализованная без ненужного максимализма, это для серьезных систем очень хорошо, но "кажется" на хлеб не намажешь. :)

Вообще-то у нас, если честно, классическая трехзвенка не вырисовывается, получается пока 2-х, 3-х и 4-х одновременно: браузер - web сервер - сервера приложений - СУБД + толстый клиент - сервера приложений - СУБД + СУБД - средства для многомерного анализа + сюда же добавляется связка собcтвенной СУБД бухгалтерии с нашей СУБД с перекачкой части нужных данных средствами самой СУБД (фиг знает, в качестве какой звенности это рассматривать).

Знаю одно, что ничего хуже чем вынесение БЛ в больших системах на толстого клиента нет. Ну, вот такое сложилось личное мнение, что почти что угодно, только не это.
Хорошо что хоть это было не мое решение, зато сейчас "радуемся" унаследованным проблемам. :(
...
Рейтинг: 0 / 0
27.02.2010, 17:25
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36492577
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АнатоЛой
Участник
Чуть-чуть офф-топа:

carperOracle Да (PL/SQL)
...
DB2 Да (SQL/PL)

Что интересно, не так давно IBM заявило для DB2 поддержку Oracle'ового PL/SQL (естественно, с некоторыми ограничениями). Нацеленность понятна: упростить миграцию Oracle => DB2. Обратная сторона медали: может стоит под DB2 писать не на родном SQL/PL, а на Oracle'овом PL/SQL?
...
Рейтинг: 0 / 0
27.02.2010, 17:25
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36492691
tadmin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tadmin
Участник
Все, я смотрю, закладываются на независимость от производителя БД. Мудро.
А что лучше сохраняет совместимость и живет дольше: БД или платформа, на которой пишут сервер приложений или клиента?
...
Рейтинг: 0 / 0
27.02.2010, 19:07
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36492727
web_fox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
web_fox
Участник
carper,

авторТак?
Разумный анализ.
Спасибо, что довели дело до конца и подвели итоги. Это заслуживает уважения.

PS
Цитата

авторполностью доверять ORM можно только на сверх-малых объемах данных. Как только данных станет больше 1М записей в таблицах - могут начать вылезать косяки (зависит от железа и других параметров).

К примеру отсутствие индекса на JOIN или WHERE приводит к полному скану таблицы и тормозам система. Система работает правильно с технической точки зрения, но неправильно с пользовательской, когда на "элементарное" с т.з. пользователя действие система думает по 2-3 минуты.

Или вообще шедевр - строка как первичный ключ

PS ORM пытается скрыть КАК информация хранится и обрабатывается в СУБД, но "Закон дырявых абстракций" все равно пролезает. Потому проект без грамотного БД-программиста всегда дохнет уже на среднем объеме инфы.

/topic/598629&hl=er+%e4%e8%e0%e3%f0%e0%ec%ec%e0+%ea%eb%e0%f1%f1%fb
...
Рейтинг: 0 / 0
27.02.2010, 19:59
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36492740
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
АнатоЛойне так давно IBM заявило для DB2 поддержку Oracle'ового PL/SQL

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


tadminВсе, я смотрю, закладываются на независимость от производителя БД. Мудро.

Эх, если бы это можно было сделать без столь больших жертв... :(

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

авторА что лучше сохраняет совместимость и живет дольше: БД или платформа, на которой пишут сервер приложений или клиента?

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

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

Остальное, хотя и болезненно, но не смертельно. Срок же жизни БД обычно гораздо больше, по объективным причинам, что совсем не значит, что вам не придется срочно менять как раз базу данных, особенно если вы плохо просчитали рынок и производитель вашей базы тихо почил.
Да и вообще, существует огромный слой приложений которым база нужна постольку-поскольку, вот они уж точно могут особенно не заморачиваться сроком жизни БД.
...
Рейтинг: 0 / 0
27.02.2010, 20:14
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36492852
Mожет быть и Я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mожет быть и Я
Гость
2 carper,один набор банальностей и несуразностей. Учите уж лучше маркетингу, а не программированию
...
Рейтинг: 0 / 0
27.02.2010, 22:37
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36492908
ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКС
Гость
Mожет быть и Я2 carper,один набор банальностей и несуразностей. Учите уж лучше маркетингу, а не программированию

Многие через это проходят.
И написание банальных "универсальных систем", которые потом поддерживать другим людям приходится, и наивное студенческое размещение валидации на клиенте со словами "а, это ведь монопольное использование - значит, данным можно верить".
Опыт, все опыт.
...
Рейтинг: 0 / 0
27.02.2010, 23:59
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36492924
Не универсальная система
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Не универсальная система
Гость
ОКСMожет быть Я2 carper,один набор банальностей и несуразностей. Учите уж лучше маркетингу, а не программированию

Многие через это проходят.
И написание банальных "универсальных систем", которые потом поддерживать другим людям приходится, и наивное студенческое размещение валидации на клиенте со словами "а, это ведь монопольное использование - значит, данным можно верить".
Опыт, все опыт.
Еще одна банальность с абстрактными рассуждениями на общую тему. Системы бывают разными, с разными требованиями. Чем плохи проверки на клиенте(обязательное поле, допустимый диапазон, отсутствие дубликатов и тд)? Нужно гонять мусор по сети, а потом вываливать пользователю ворох ошибок, в которых он будет три часа ковыряться?
...
Рейтинг: 0 / 0
28.02.2010, 00:37
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36492930
Не ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Не ОКС
Гость
Не экономьте на спичках, закупайте нормальные системы, а не поделки студентов. Учитесь лучше сами(экономике), а не учите других
...
Рейтинг: 0 / 0
28.02.2010, 00:43
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36492979
ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКС
Гость
Чтобы закупить "нормальные системы" вполне достаточно людей, которые учились экономике.

Затем, чтобы заставить работать купленную систему - обращаются к разработчикам, аналитикам, проектировщикам, администраторам БД...

Хотя несомненно, на закупках зарабатывают больше. ;)
...
Рейтинг: 0 / 0
28.02.2010, 01:49
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36492989
Не ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Не ОКС
Гость
ОКС
Затем, чтобы заставить работать купленную систему - обращаются к разработчикам, аналитикам, проектировщикам, администраторам БД...

В таком случае - не экономьте на разработчиках. Не нужно будет читать лекции студентам ;-)
...
Рейтинг: 0 / 0
28.02.2010, 02:23
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36493004
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
театр одного актёра?
...
Рейтинг: 0 / 0
28.02.2010, 03:51
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36493059
Не ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Не ОКС
Гость
egorychтеатр одного актёра?
Театр абсурда. Те, кто у кормушки, пытаются учить проектированию, чтобы потом откат был жирный и на студентах не разориться
...
Рейтинг: 0 / 0
28.02.2010, 10:34
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36493115
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
egorychтеатр одного актёра?
модератор может уточнить, но по на вскиду - да.
...
Рейтинг: 0 / 0
28.02.2010, 12:11
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36493245
Егоров Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Егоров Александр
Участник
carpertadminВсе, я смотрю, закладываются на независимость от производителя БД. Мудро.Эх, если бы это можно было сделать без столь больших жертв... :(

Именно для этого плодят стандарты, на которые производители не то чтобы кладут, но как-то весьма своеобразно им следуют, приблизительно как сдаче кандидатского минимума - философию надо сдать всем, а защищаться можешь хоть по химии, хоть по политэкономии. :(Производители не то, чтобы кладут на стандарты, производители обычно расширяют стандарт. Причем так, что стандартом уже как-то и не особо хочется пользоваться... :)
запрос, написанный на SQL-92, выполнится одинаково и на MSSQL, и на Oracle. Но одна и таже процедура на T-SQL и PL\SQL - это действительно две разных процедуры. Иногда даже абсолютно разные :)
...
Рейтинг: 0 / 0
28.02.2010, 14:13
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36493510
ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКС
Гость
Не универсальная системаЧем плохи проверки на клиенте(обязательное поле, допустимый диапазон, отсутствие дубликатов и тд)? Нужно гонять мусор по сети, а потом вываливать пользователю ворох ошибок, в которых он будет три часа ковыряться?

Проверки на клиенте - хорошая практика. Да, например, для удобства пользователя. Я разве спорю?
Я говорю о том, что прежде чем выполнять операцию с представляющими ценность данными, следует проверять их на сервере.
Иначе где гарантия, что до сервера дошли именно те данные, которые были проверены на клиенте?
Или что клиентское ПО не подменили?
...
Рейтинг: 0 / 0
28.02.2010, 19:11
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36493516
ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКС
Гость
iscrafmegorychтеатр одного актёра?
модератор может уточнить, но по на вскиду - да.
iscrafm
Костя отвечай уже под своим ником.

У тебя и с интуицией так же плохо, как с проектированием. )))
...
Рейтинг: 0 / 0
28.02.2010, 19:17
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36493660
Не ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Не ОКС
Гость
ОКСНе универсальная системаЧем плохи проверки на клиенте(обязательное поле, допустимый диапазон, отсутствие дубликатов и тд)? Нужно гонять мусор по сети, а потом вываливать пользователю ворох ошибок, в которых он будет три часа ковыряться?

Проверки на клиенте - хорошая практика. Да, например, для удобства пользователя. Я разве спорю?
Я говорю о том, что прежде чем выполнять операцию с представляющими ценность данными, следует проверять их на сервере.
Иначе где гарантия, что до сервера дошли именно те данные, которые были проверены на клиенте?
Или что клиентское ПО не подменили?
Осталось еще рассказать, как ваш сервер узнает, что данные никто не подменил. Не театр - кино.
...
Рейтинг: 0 / 0
28.02.2010, 21:55
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36493671
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Клинт Иствуд, со своей подменой, действительно отдыхает. Осталось титров этого кино дождаться
...
Рейтинг: 0 / 0
28.02.2010, 22:18
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36493980
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
carperПодобъем предварительные итоги:
...
Так?Многое из сказанного верно, но, на мой взгляд, имеет малое отношение к вопросу выбора места реализации бизнес-логики. Особенно учитывая то, что практически все приведенные преимущества и недостатки сразу же дезавуированы.
Я бы рассматривал вопрос в несколько иной плоскости. Архитектуру надо выбирать исходя из эффективности решения большинства задач, и предусматривать то, что из любых правил будут исключения. Буду исходить из предположения о том, что система будет жить долго, активно модифицироваться и дорабатываться. В этом случае архитектура должна обеспечить как минимум две вещи - простоту интеграции (с учетом перспектив развития методов интеграции) и простоту модификации.
1. Интеграция. На данный момент времени лидирующей технологией в этом направлении, кажется, является SOA. Не буду обсуждать перспективы (это где-то в соседнем топике), но сейчас это востребовано. И тут без сервера приложений жить неудобно. То есть трехуровневая архитектура - почти неизбежный выбор. Несомненно, даже при наличии сервера приложений родные клиенты могут ходить в базу напрямую, но мне не кажется это разумным. Кроме того, сейчас есть огромная мода (хотя на практике это мало кому надо) на web-интерфейсы. В рамках этого пункта можно рассмотреть высказываение с которым трудно согласиться:carperЗа одним НО - число приложений, умеющих работать с СУБД, на несколько порядков больше, чем с нашим сервером приложений. Если придумывать собственные пртоколы для интерфейса сервера приложений, то это может быть и верно, но есть типовые протоколы. Сейчас систем, умеющих вызывать, например, веб-сервисы ничуть не меньше, чем умеющих присоединяться к базе данных.
2. Простота модификации. Тут стоит отметить, что лучшей документацией всегда является код. Поэтому стоит расчитывать на то, что те, кто будут что-то модифицировать в первую очередь попытаются разобаться в коде. Чем меньше языков использовано при написании кода, тем легче будет разобраться. Дополнительной сложностью при размазывании бизнес-логики на несколько уровней является и то, что почти наверняка возникнет потребность из элемента, реализованного на нижнем уровне, вызвать элемент, реализованный на верхнем. Изящно решить эту проблему не всегда удается.
Исходя из этого стоит стремиться всю бизнес-логику реализовать в рамках одного слоя. По моим ощущениям это можно сделать всегда. Правда изредка это может быть не самым эффективным (в основном с точки зрения использования вычислительных ресурсов) решением. Но таких случаев очень мало и не стоит эти исключения возводить в правило.
Ну и если уж делать бизнес-логику в рамках одного слоя, то надо решить что это будет - СУБД или СП. Основным аргументом тут будет, наверное, квалификация разработчиков. Если большая часть прикладных программистов - "базисты", то стоит выбрать ХП. Если "жависты", то СП. Если же абстрагироваться от квалификации, то я бы рекомендовал СП - во-первых, языковые средства для СП более выразительны (не стоит сбрасывть со счетов ООП), а во-вторых, по-моим ощущениям, задач которые решаются на СП эффективнее, чем в БД больше, чем тех, что эффективнее решаются в БД. Хотя подавляющее большинство задач решаются одинаково эффективно. Естественно, специфика конкретной задачи может сместить акценты, я ориентировался на некое собственное представление о типовой учетной системе.
...
Рейтинг: 0 / 0
01.03.2010, 10:17
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36494762
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
Bogdanov Andrey,
Код: plaintext
1.
Чем меньше языков использовано при написании кода, тем легче будет разобраться. Дополнительной сложностью при размазывании бизнес-логики на несколько уровней является и то, что почти наверняка возникнет потребность из элемента, реализованного на нижнем уровне, вызвать элемент, реализованный на верхнем. Изящно решить эту проблему не всегда удается.

Код: plaintext
Правда изредка это может быть не самым эффективным
Изредка?


Меня многое смущает, но прежде всего то, что одной из идей, как мне кажется, 3-х звенного приложения является разделение сфер ответственности, например, не должна СУБД общаться с клиентами.

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

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

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

Кто сказал, что перенеся логику на СП мы сможем отказаться от спецов по работе с БД?
Пока это как-то совсем не очевидно.

Да, касательно языков программирования, например, в Oracle нам никто не мешает использовать JAVA на всех уровнях, в Ms SQL .NET ...

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

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

Но, в любом случае, обсуждение получается любопытным.
...
Рейтинг: 0 / 0
01.03.2010, 14:01
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36494770
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
Приношу всем извинения за длиннющие строки.
Что-то сглючило в движке форума, я
такое не писал. :(
...
Рейтинг: 0 / 0
01.03.2010, 14:04
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36494788
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
carperПриношу всем извинения за длиннющие строки.
Что-то сглючило в движке форума, я
такое не писал. :(
Вы просто вместо QUTE использовали SRC, переноса по словам в нем нет.
...
Рейтинг: 0 / 0
01.03.2010, 14:09
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36494936
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
iscrafm,

Ага, а что я использовал в своем тексте? :)
...
Рейтинг: 0 / 0
01.03.2010, 14:55
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36494968
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
carperiscrafm,

Ага, а что я использовал в своем тексте? :)
вместо цитаты, тег для выделения исходного текста. В нем нет переноса по словам.
...
Рейтинг: 0 / 0
01.03.2010, 15:04
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36494988
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
carper
Правда изредка это может быть не самым эффективным
Изредка?
Почти в любом приложении подавляющая часть всего кода тривиальна и надо постараться, чтобы написать его неэффективно. Да и большая часть функционала обычно крайне нетребовательна (обычно десяток элементарных справочников на одну серъезную операцию :) ). Другое дело, что крайне малая нетривиальная часть всегда наиболее заметна.

carper
Меня многое смущает, но прежде всего то, что одной из идей, как мне кажется, 3-х звенного приложения является разделение сфер ответственности, например, не должна СУБД общаться с клиентами.

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

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

carperКто сказал, что перенеся логику на СП мы сможем отказаться от спецов по работе с БД?Я такого точно не говорил :)

carperЯ описал свое видение БЛ на СУБД просто как попытку уйти от парадигмы работы с таблицами на парадигму работы с примитивными операциями, скрывающими внутреннюю структуру базыЯ об этом писал в ответ web_fox - вы предпочитаете в бизнес-логике оперировать нереляционной моделью данных. Это нормально. Но я считаю, что эту нереляционную модель удобнее реализовывать не средствами реляционной БД, а другими средствами.
...
Рейтинг: 0 / 0
01.03.2010, 15:10
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36495495
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
Bogdanov Andrey,
авторПочти в любом приложении подавляющая часть всего кода
тривиальна и надо постараться, чтобы написать его неэффективно.

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


авторМне кажется, что модуль должен включать некоторую относительно замкнутую часть функционала.

Вообще-то я о том же. Так ХР "добавление пользователя" вполне себе замкнуто знает имена таблиц и процедур задействованных при этом самом добавлении, предназначенных для проведения целостной транзакции.

А бизнес-функция "добавление-пользователя", лежащая на СП отвечает за бизнес-логику уровня приложения, например, проверяет откуда и кто производит добавление, определяет правила наименования пользователя и т.п.
После чего вызывает одноименную ХР.
Никакого дублирования ни логики ни поведения здесь вроде как нет.

Я могу писать ХР, при утвержденной архитектуре СУБД, ничего не зная о сервере приложений, более того, вообще не завися от того на какой стадии разработки он находится, и наоборот СП может реализовать любую бизнес-логику, не ожидая реализации ХР, ну, в крайнем случае задействует моки.


авторНо я считаю, что эту нереляционную модель удобнее реализовывать не средствами реляционной БД, а другими средствами.

Еще как удобней, но на практике получается не очень.
Идеальным бы было решение использовать ООП и на уровне СУБД, но тут сразу начинается слишком много разных гитик. :)
Да и от "проклятого вопроса, где же держать логику" ' это не поможет.
...
Рейтинг: 0 / 0
01.03.2010, 17:53
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36496816
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
carperВообще-то я о том же. Так ХР "добавление пользователя" вполне себе замкнуто знает имена таблиц и процедур задействованных при этом самом добавлении, предназначенных для проведения целостной транзакции.Да. каждую процедуру можно считать модулем, но это не удобно. Цель разбиения функционала на модули - сделать количество взаимодествующих элементов на каждом уровне абстракции поддающимся осмыслению. Если у нас всего 100 программных единиц, то разумно иметь 10 модулей по 10 программных единиц в каждой. Для бОльших систем и модули стоит рассматривать более крупные. В какой-то момент стоит вводить уже "трехуровневую" классификацию подсистема-модуль-элемент и мириться с дублированием функционала в разных подсистемах ради того, чтобы сохранить управляемость.
Посему рассуждая о "модулях" я все-таки имею ввиду нечто большее чем один класс или одну процедуру.
carperПосле чего вызывает одноименную ХР.
Никакого дублирования ни логики ни поведения здесь вроде как нет.Естественно так делать можно. Другой вопрос - нужно ли. Если эта одноименная ХП вызывается ровно в одном месте, то возникает вопрос - зачем "разрывать функционал" - с равным успехом можно все сделать на СП и код вряд ли станет менее прозрачным.
...
Рейтинг: 0 / 0
02.03.2010, 13:05
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36497620
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
Bogdanov Andrey,

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

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

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

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

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

В-четвертых, легче найти грамотного DBA, разбирающегося в том же PL/SQL, чем в C#.

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

В-шестых, использование ХР позволяет в полной мере задействовать средства безопасности СУБД.
Вот простой пример: в Oracle ХР по-умолчанию запускается с правами создателя, таким образом, дав другой роли право на выполнение пакета, не надо давать ей никаких прав на отдельные составляющие, что более чем удобно и просто.
Т.е. не написав ни строчки кода, я получаю очень удобную вещь.

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

Да, мы можем это сделать, но вопрос - зачем?

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

В-седьмых, что если мы придем к выводу, что для привлечения заказчиков, нам надо бы сделать наше приложение, написанное на Delphi, например, кроссплатформенным, хотя бы потому, что тогда ему придется платить деньги только за наш СП, а не за Windows ?

ХР снимут часть проблем по переходу на другую платформу.
Я уже писал, что не думаю, что очень большую часть, но даже 5-10% это для такого кардинального дела могут оказаться решающими.


Т.е. я пока не нашел места, где недьзя обойтись без использования ХП, да, вроде как и обходятся же!, зато видится, что соотношение преимуществ/недостатков предлагаемого подхода слегка перевешивает, разумеется в общем случае, хранение всего на СП.
...
Рейтинг: 0 / 0
02.03.2010, 16:10
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36498012
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Часть аргументов, конечно надумана, c некоторыми согласен. Вопрос в том, пересилят ли эти аргументы отрицательные стороны разделения логики на разные слои.
Основные, на мой взгляд, отрицательные стороны - сложность анализа кода и проблемы с управлением изменениями. По своему опыту могу сказать, что проблема синхронизации изменений и "выставления" синхронизированных патчей многими компаниями до сих пор толком не решена - постоянно приходят обноления модулей с забытыми ХП или наоборот. Не могу сказать, что решений не существуют, но они зачастую административного характера, а следовательно крайне ненадежны. Собственно одним из существенных аргументов при начале разработки собственного фреймворка очень часть указывается простота (правда большинством недостигаемая :) ) синхронизации изменений слоев.

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

carperВо-вторых, когда возникнет вопрос использования не "в одном месте", что делать?
Мне кажется, что XП могут дать более универсальный ответ на этот вопрос.Не только ХП допускают повторное использование.

carperВ-третьих, если надо будет поддерживать несколько СУБД, НЕ поступаясь даваемыми ими преимуществами, то, при реализации низкоуровневой логики на ХП, изменения на СП будут минимальными, зачастую просто сведутся к изменению синтаксиса вызова ХП.А то, что все ХП придется переписывать вы забыли?

carperВ-четвертых, легче найти грамотного DBA, разбирающегося в том же PL/SQL, чем в C#.Согласен, но зачем DBA должен разбираться в C#?

carperВ-шестых, использование ХР позволяет в полной мере задействовать средства безопасности СУБД.Все верно, но должен сказать, что почти все СП, которые я видел использовали для хода в СУБД одну и ту же учетную запись. Так что возможность осталась неиспользованной.

carperВ-седьмых, что если мы придем к выводу, что для привлечения заказчиков, нам надо бы сделать наше приложение, написанное на Delphi, например, кроссплатформенным, хотя бы потому, что тогда ему придется платить деньги только за наш СП, а не за Windows ?

ХР снимут часть проблем по переходу на другую платформу.Чуть выше вы писали, что ХП помогут при смене СУБД, теперь, что они помогут при смене СП. Немного противоречиво :)
...
Рейтинг: 0 / 0
02.03.2010, 18:03
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36498308
Не ОКС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Не ОКС
Гость
ООП моожно прекрасно сочетать с ХП. Все споры возникают из-за попыток скрыть свой флюс и только.
...
Рейтинг: 0 / 0
02.03.2010, 21:19
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36499458
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
Не ОКС,
авторЧуть выше вы писали, что ХП помогут при смене СУБД, теперь, что они помогут при смене СП. Немного противоречиво :)
Почему? И там и там помогут. Другой разговор насколько. :)

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

авторА то, что все ХП придется переписывать вы забыли?
Ни в коей мере не забыл. Я пытался сказать, что дописать сами ХП может оказаться проще, чем дописывать соотв. логику на СП.

авторСогласен, но зачем DBA должен разбираться в C#?
Затем, что я сомневаюсь в том, что СП написан на PL/SQL.

авторВсе верно, но должен сказать, что почти все СП, которые я видел использовали для хода в СУБД одну и ту же учетную запись. Так что возможность осталась неиспользованной.
А я видел СП, работающий через proxy пользователей, что давало множество преимуществ.
А еще я не понимаю, зачем использовать одну учетку - что это "так уж получилось" понятно, но при новых разработках что это даст, кроме не очень существенных плюсов в реализации кэша коннектов в интернет приложении (да и тут зачем один пользователь? Используйте группы.)?


Мы еще не коснулись темы кривости ORM, например, в Hibernate использовать аннотации типа @SQLInsert, вызывающие хранимые процедуры с параметрами (будем считать это тем самым частным случаям, когда это действительно надо), можно только упав с печки.

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

Их издевательская рекомендация звучит так - "фиг его знает в каком порядке, чего наш Hibernate там будет связывать - запустите его в отладчике, сами поймете."
(Она не изменилась на сей день - только что проверил.)

Т.е. я вынужден настраивать процедуру на дебаггер Hibernate!
И молиться, чтобы при выходе новой версии, случайном изменении следования строк кода (ага, он умудряется маппить параметры в порядке объявления аннотаций, даже не в алфавитном наименовании полей) и т.п. у меня вдруг не перестало все работать (да бог бы с ним "перестало", но вот забудь я перекрыть юнит тестом проверку того, что у меня вместо имени не вставляется фамилия и привет - спохватиться можно слишком поздно).

И вообще, заходишь на баг-трекер того же Hibernate и думаешь: "как это вообще еще работает"? :)
И бог бы с ними, с ошибками, система живая, развивается, ошибки неизбежны, но ведь править их что-то никто не рвется.
Частенько можно прочитать фразу, типа "You need named parameters. OK. Do it yourself." и замечательный статус "closed".

Т.е. не практике еще выходит, что чем меньше мы зависим от ORM тем меньше мы ошибок наплодим, т.к. нативные языки для ХП пишутся гораздо более серьезными командами и тестируются несопоставимым кол-ом пользователей.
Даже в пределах одной компании - тот же TopLink, подвергается каждодневным проверкам на вшивость и удобство в гораздо меньшей степени, чем PL/SQL.
Т.к. Oracle вообще-то TopLink не так чтобы уж очень задался, может вообще community отдать.
...
Рейтинг: 0 / 0
03.03.2010, 12:36
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36499635
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
carperМне просто кажется, что повторное использование ХП проще, чем повторное использование API СП, хотя бы потому, что API ХП понимает гораздо большее число приложений и не надо городить ужас с передачей всего и вся через XML и прочую хрень.Я тоже больше разработчик СУБД, посему понимаю ваши слова об ужасе, но, поверьте, вы не совсем правы. Просто вы (в общем-то, также как и я) плохо знакомы с технологиями взаимодействия приложений. Но например, мне кажется, что из Visual Basic com-объект подцепить проще, чем ХП.

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

carperавторСогласен, но зачем DBA должен разбираться в C#?
Затем, что я сомневаюсь в том, что СП написан на PL/SQL.Пока не улавливаю связи. DBA занимается своими вопросами - зачем ему лезть в код СП - мне не понятно. Если он видит, что в базу данных приходят "плохие" запросы, то он должен дать рекомендации по их "улучшению". В код СП для этого лезть не надо.

carperА еще я не понимаю, зачем использовать одну учетку - что это "так уж получилось" понятно, но при новых разработках что это даст, кроме не очень существенных плюсов в реализации кэша коннектов в интернет приложении (да и тут зачем один пользователь? Используйте группы.)?Тут правильнее поставить вопрос по-другому - а что дает использование "разных учеток"? Очевидно, что с одной учеткой разработывать проще.
Дело в том, что система раздачи прав на некие "интерфейсные элементы БД" нафиг никому не нужна - этим очень трудно управлять. Для использования нужна система раздачи прав на некие понятные пользователю, а не разработчику элементы. Есть в экранной формочке кнопка - надо иметь возможность дать (или отнять) права на эту кнопку, а не на те три десятка процедур, которые за этой кнопкой скрываются.

carperМы еще не коснулись темы кривости ORM, например, в Hibernate ...К сожалению, обсуждение этой темы я поддержать не могу, ввиду недостаточного опыта работы с Hibernate, да и считаю, что в рамках данной темы это оффтопик.

Ну и в заключение - я уже писал, что согласен с некоторыми преимуществами, которые дают ХП - нет нужды расписывать эти преимущества еще и еще раз. Но я вижу и кучу недостатков. И на данный момент не вижу, чтобы преимущества перевешивали недостатки.
...
Рейтинг: 0 / 0
03.03.2010, 13:26
| Ответить | Цитировать | Написать  
318 сообщений из 318, показаны все 13 страниц
  все  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Где должна лежать бизнес-логика в мнгоуровневом приложении
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=32&tid=1542824]:
 0ms
get settings:
 7ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 177ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 202ms
get tp. blocked users:
 1ms
others: 234ms
total:  654ms
созд. / загр.: 654ms
x
x
Закрыть


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