Расположение бизнес логики приложения.

← →
Sectey © (2004-08-02 15:07) [0]

Добрый день уважаемые мастера.
Передо мной стоит задача разработки довольно объемного приложения. Технология клиент-сервер. У меня не возникал вопрос по поводу расположения бизнес - логики. Я всегда использовал комбинированный подход. А тут возникло желание максимально перенести ее на сервер. Так вот вопрос насколько это является грамотным и целесообразно ли это?

← →
Johnmen © (2004-08-02 15:10) [1]

Вопрос слишком абстрактный.
В целом - явл.грамотным и целесообразно.

← →
Digitman © (2004-08-02 15:15) [2]

централизация бизнес-логики всегда целесообразна

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

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

← →
Sergey_Masloff (2004-08-02 16:04) [3]

Я "фанат" ;-) серверной логики но не всегда это работает эффективно. Скажем довольно обидно пользователю введя много данных получить отлуп от сервера (да и серверу лопатить впустую лишнее неразумно).
Для себя я нашел частичное решение - стараюсь ту бизнес-логику что уместна на клиенте на нем и реализовать но управлять ей с сервера ;-) Ну например какие поля обязательны для заполнения, форматы полей, ограничения - все проверяет клиент но данные для проверки он получает при коннекте к серверу. То есть форма открываясь первым делом запрашивает у сервера инициализационные данные, настраивает себя и только потом пользователь ее получает в свое распоряжение. Скажем поступила вводная что такое-то поле стало обязательным а это позволяет только ввод цифр - меняется пара строк в процедуре на сервере и все клиенты тут же начали работать по-новому. По умному называется data-driven application. Конечно первоначальные затраты на разработку фреймворка довольно большие но потом себя окупает.

← →
Anatoly Podgoretsky © (2004-08-02 16:17) [4]

Много звенная архитектура, отчасти и придумана для этого. Разделение по слоям.

← →
Ega23 © (2004-08-02 16:18) [5]

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

← →
Johnmen © (2004-08-02 16:21) [6]

>Ega23 © (02.08.04 16:18) [5]

Нельзя. По определению...

← →
Sergey_Masloff (2004-08-02 16:26) [7]

Johnmen © (02.08.04 16:21) [6]
>Нельзя. По определению...
Что за определение такое?
Есть мнение (и не только мое ;-))

- Слой хранения данных (таблицы и триггеры)
- Слой бизнес-логики (ХП)
- Презентационный слой

Самая что ни на есть трехзвенка.

← →
Соловьев © (2004-08-02 16:33) [8]

> Самая что ни на есть трехзвенка.

TDataSet=>TDataSource=>TDBGrid - чем не трехзвенка ?:)

← →
Johnmen © (2004-08-02 16:35) [9]

>Sergey_Masloff (02.08.04 16:26) [7]

Хочешь поговорить об определениях ?
:)

← →
Ega23 © (2004-08-02 17:22) [10]

Соловьев © (02.08.04 16:33) [8]

А если Master->Detail на три грида?
TDataSet=>TDataSource=>TDataSet=>TDataSource=>TDataSet=>TDataSource=>TDBGrid?

Тогда что, семицветик, блин?

Johnmen © (02.08.04 16:35) [9]
Хочешь поговорить об определениях ?

Эти определения не более чем условности, Application Server и на ХП можно организовать, было-бы желание.

← →
Sergey_Masloff (2004-08-02 17:23) [11]

Johnmen © (02.08.04 16:35) [9]
>Хочешь поговорить об определениях ?
Можно было б, жаль времени нет.

Соловьев © (02.08.04 16:33) [8]
бизнес-логика в датасорсе, видимо?

← →
Johnmen © (2004-08-02 17:52) [12]

Видимо у нас разные понятия, что такое "звено" в многозвенных архитектурах...

← →
Sergey_Masloff (2004-08-02 17:56) [13]

Johnmen © (02.08.04 17:52) [12]
>Видимо у нас разные понятия, что такое "звено" в многозвенных >архитектурах...
Да фиг с нами, у самих отцов-основателей и то по этому вопросу разные понятия. Все равно реальную систему в строгое стойло теории не вогнать ;-)

← →
Johnmen © (2004-08-02 18:03) [14]

>Sergey_Masloff (02.08.04 17:56) [13]

С нами не только фиг ! Но и всё остальное...:)
Но в данном конкретном случае, написав пару ХП, говорить о многозвенности, право, не стОит.

← →
Sergey Masloff (2004-08-02 20:16) [15]

Johnmen © (02.08.04 18:03) [14]
Пару? Знаешь, у нас код больше миллиона строк в них сидит а сколько процедур... не знаю не считал я. Много-много тысяч ;-) По крайней мере раз в 100 больше логики чем на клиенте а формальный сервер приложений (который AppServer) у нас просто труба через которую данные качаются. А ты говоришь пару...
Получилось похоже на замер первичных половых признаков но я не с той целью - думаю ты понимаешь.

← →
Johnmen © (2004-08-03 09:17) [16]

>Sergey Masloff (02.08.04 20:16) [15]

Да я то понимаю. Но разговор шел не про твой проект...:)
И про пару ХП - это лишь образное выражение.

← →
Sandman25 © (2004-08-03 09:28) [17]

Кстати, не вижу принципиальной разницы между 1 ХП и 1000 ХП.
Аналогия - даже если в БД находится 1000 таблиц, это не делает БД распределенной :)

← →
Соловьев © (2004-08-03 09:35) [18]

>
> TDataSet=>TDataSource=>TDataSet=>TDataSource=>TDataSet=>TDataSource=>TDBGrid?
>
>
> Тогда что, семицветик, блин?

> бизнес-логика в датасорсе, видимо?

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

← →
Sergey_Masloff (2004-08-03 09:36) [19]

Sandman25 © (03.08.04 09:28) [17]
>Кстати, не вижу принципиальной разницы между 1 ХП и 1000 ХП.
Вобщем, да. Но если в ХП сосредоточено 95% бизнес-логики приложения это делает сервер БД одновременно и сервером приложений. То есть "средним" звеном. Физически звено одно логически - разные. И действительно если даже эта ХП - единственная.

← →
Sandman25 © (2004-08-03 09:37) [20]

[19] Sergey_Masloff (03.08.04 09:36)

Умом понимаю, но сердцем принять не могу. Уж извините :)

← →
Sergey_Masloff (2004-08-03 09:41) [21]

Соловьев © (03.08.04 09:35) [18]
>Трехзвенка предпологает наличия промежуточного звена, который и >делает всю черновую работу с БД,
ДА
>причем предпологается >независимость от СУБД
НЕТ
Впрочем, предполагать каждый волен по-своему. Дейт и Фаулер явным образом полагают ровно как я. Уверен что есть сторонники и вашей теории, в том числе и в среде видных теоретиков. Я утверждаю что БИЗНЕС логика и в моем случае может быть ПОЛНОСТЬЮ отделена от логики хранения данных несмотря на реализацию предлагаемую средствами сервера СУБД

← →
Polevi © (2004-08-03 10:39) [22]

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

[18]
>А У Вас получается что ХП зависит, тем более не все СУБД поддерживают ХП, а если и поддерживают - так разный синтаксис.

Всё правильно! Ведь есть трёхзвенные СУБД и не-трёхзвенные СУБД =). Поэтому вторые субд так и пишутся - субд - маленькими буквами.

← →
Sergey_Masloff (2004-08-03 10:56) [24]

Polevi © (03.08.04 10:39) [22]
>возможностей MSSQL достаточно для реализации бизнес-логики в >хранимых процедурах
Смотря какая логика. Для некоторой и интербейза хватит. У MSSQL возможностей не больше чем у ORACLE, DB2 и др. "одноклассников".

> [24] Sergey_Masloff (03.08.04 10:56)
он умеет работать с xml, это очень много

← →
Sergey_Masloff (2004-08-03 11:48) [26]

Polevi © (03.08.04 11:39) [25]
>он умеет работать с xml, это очень много
ORACLE тоже умеет
Более того и Интербейз можно научить ;-)
Да нет я не спорю MSSQL, даже очень. Просто по большому счету возможности равны просто нюансы есть везде свои.

да я не утверждаю что MSSQL "круче", просто автор ветки его использует

Я премного обязан всем участникам данной ветки.
На данном этапе разработки проекта, я не хочу идти в "трехзвенном" направлении. Для реализации сервера приложений в полной мере у меня не хватит временных ресурсов. А делать для того чтобы было мне представляется не целесообразным. Мое мнение, максимум БЛ на сервере, ну а что не получится на клиенте.
>Sergey_Masloff
Мне очень любопытен ваш подход к данному вопросу. Если не возражаете, могу ли я связаться с вами по данному вопросу немного попозже?

← →
Sergey_Masloff (2004-08-03 12:48) [29]

Polevi © (03.08.04 11:55) [27]
>да я не утверждаю что MSSQL "круче", просто автор ветки его >использует
Прошу прощения. Я (ошибочно) воспринял твой ответ как относящийся не к первоначальному вопросу а как к дальнейшему обсуждению. Если это ответ на изначальный вопрос то он абсолютно справедлив тут и спорить не о чем.

← →
Sergey_Masloff (2004-08-03 12:50) [30]

Sectey © (03.08.04 12:19) [28]
>Если не возражаете, могу ли я связаться с вами по данному вопросу немного попозже?

Да без проблем. Правда мой опыт именно в MSSQL крайне невелик но какие-то консультации - всегда пожалуйста.

Соловьев © (03.08.04 09:35) [18]

Я ещё раз повторюсь, что на MS SQL можно с помощью ХП AppServer организовать. Достукиваться до других баз, запуск внешних программ/команд, и т.п. Если у вас есть желание, то почитайте про системные ХП.

>Sergey_Masloff
Забание спасибо. Просто меня заинтересовал подход управление с сервера БД сервером приложений.

Расположение бизнес логики приложения. Найти похожие ветки