ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Где должна лежать бизнес-логика в мнгоуровневом приложении
25 сообщений из 318, страница 2 из 13
  2  все
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #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
| Ответить | Цитировать | Написать  
25 сообщений из 318, страница 2 из 13
  2  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Где должна лежать бизнес-логика в мнгоуровневом приложении
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=36441195&tid=1542824]:
 0ms
get settings:
 10ms
get forum list:
 11ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 145ms
get topic data:
 7ms
get forum data:
 2ms
get page messages:
 42ms
get tp. blocked users:
 1ms
others: 228ms
total:  450ms
созд. / загр.: 450ms
x
x
Закрыть


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