Надобность App-server-а при использовании MS SQL

← →
Nikolay M. (2003-12-26 11:59) [0]

Недавно попросили меня нарисовать на бумажке инфраструктуру некоторой большой системы. Нарисовал много всяких квадратиков, в том числе и мидл-уровень и тонких клиентов. Задали вопрос - а зачем нужен мидл-уровень? Задумался: разграничение прав доступа делается самим MS SQL-ем, бизнес-логику, сложные запросы и тп. производительнее делать на ХР. При использовании АДО толстый клиент по объему практически равен тонкому. Обновление клиента до новой версии идентично как и в случае тонкого клиента.
Тогда что остается на мидл-уровне? Получается, что выигрываем только в удобстве развертывания, масштабируемости, переносимости между разными СУБД, Т.е. имеем только бОльшее удобство разработки и сопровождения (хотя тоже спорный вопрос), но не бОльшую производительность и надежность работы самой системы?

← →
vuk (2003-12-26 12:09) [1]

to Nikolay M.:
>Задали вопрос - а зачем нужен мидл-уровень? Задумался<...>
Во! Задумываться надо было до рисования квадратиков. :o) Я тоже во многих случаях не вижу смысла городить промежуточный слой. Встроенной безопасности, конечно, иной раз не хватает(построчные разрешения на данные, например), но никто не мешает свою раелизовать средствами того же MS SQL, но это, конечно, в том случае, если вся работа с БД идет только через SP.

← →
Nikolay M. (2003-12-26 12:19) [2]

> Во! Задумываться надо было до рисования квадратиков. :o)

Да не, это собеседование было, поэтому наоборот надо было пальцы кинуть :)

> вся работа с БД идет только через SP

А вот это, имхо, тоже крайность. Когда на каждый селект нужно писать ХР или вьюху (маленький плюсик в пользу апп-сервера). В целях безопасности это, конечно, правильно. Но тогда серверная часть получается процедурно-ориентированной, а поддерживать потом несколько сотен ХР довольно проблематично :(

← →
vuk (2003-12-26 12:27) [3]

to Nikolay M.:
>В целях безопасности это, конечно, правильно.
Не только. Получаем еще и независимость клиентского кода от реализации логики в БД - в этом случае есть некий "процедурный API" к данным, которым пользуется клиент, а уж как хранятся данные и что там внутри происходит - не его дело.

>Но тогда серверная часть получается процедурно-ориентированной,
>а поддерживать потом несколько сотен ХР довольно проблематично
Поддерживаем несколько десятков сотен - и ничего. :o)

← →
Anatoly Podgoretsky (2003-12-26 12:31) [4]

Nikolay M. © (26.12.03 12:19) [2]
Вот тебя и попытались расколоть, понимаешь ли ты, что нарисовал и зачем.

← →
Nikolay M. (2003-12-26 12:38) [5]

> есть некий "процедурный API" к данным

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

> Поддерживаем несколько десятков сотен - и ничего. :o)

Скорее всего это ваши собственные ХР?
А вот мы поддерживаем чужие, столетней давности, написанные, к тому же per rectum :( Мат льется широкой рекой через слово.

← →
Nikolay M. (2003-12-26 12:40) [6]

> Вот тебя и попытались расколоть, понимаешь ли ты, что нарисовал и зачем.

Не получилось (расколоть) :?)))

← →
Delirium (2003-12-26 12:47) [7]

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

← →
Nikolay M. (2003-12-26 12:54) [8]

> Почему не делаем репликацию на уровне СУБД - делаем, но
> лишь отчасти - слишком не экономно в смысле траффика.

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

← →
Vuk (2003-12-26 14:10) [9]

to Nikolay M.:
>Да, хорошо, если этот АПИ со временем не меняется и из имеющихся
>кирпичиков можно строить необходимый набор данных
Процедурный интерфейс к данным строится исходя из потребностей, возникающих в конкретном месте. И решаются конкретные проблемы в функционировании приложения. То есть, если для работы нужна определенная выборка, то под это дело пишется отдельная процедура.

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

>А вот мы поддерживаем чужие, столетней давности, написанные, к
>тому же per rectum
В нашем случае, хоть все пишется и нами самостоятельно, но не всегда сразу получается правильно. Но внутренняя логика процедур всегда может быть переписана и оптимизирована. На клиенте это никак не сказывается.

← →
Delirium (2003-12-26 14:16) [10]

"репликация MS SQL работает вполне удовлетворительно" - совершенно верно, вот только данные предаются в виде скриптов, например BLOB прередаётся не как бинарный поток, а как текст:
... insert ... (...) values (..., 0x010203040A0F...)...
Что практически вдвое увеличивает траффик, а связь - модемная...
Так что после мытарств пришли к самодельной репликации на основе DTS - гораздо эффективнее.

← →
Карелин Артем (2003-12-26 14:43) [11]

У свой протол репликации с разруливанием транзакций, сжатием некоторыми самодельными фишками и тоже намного эффективнее работает на модеме. Сжатие в 5-10 раз.

← →
Nikolay M. (2003-12-26 14:47) [12]

> А нафига нужны такие процедуры? Они не решают никаких проблем
> прикладной области.

Хм. А форма с кучей DBLookupComboBox-ов - откуда ListSource для них брать?

> хоть все пишется и нами самостоятельно

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

> данные предаются в виде скриптов

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

← →
Nikolay M. (2003-12-26 14:50) [13]

> Карелин Артем © (26.12.03 14:43) [11]

Поделишься хотя бы в общих словах, как прикручивал?
Здесь или по аське?

← →
Vuk (2003-12-26 15:08) [14]

to Nikolay M.:
>Хм. А форма с кучей DBLookupComboBox-ов - откуда ListSource для
>них брать?
Ну да, оно, конечно встречается... На весь проект 15 мест, где разные варианты Lookup используются, самая большая куча - 3 LookupListBox-а. Но выборки идут не из больших таблиц и уж тем более, использовать наборы данных из таких процедур для связывания друг с другом не имеет смысла - все это справочники.

← →
Nikolay M. (2003-12-26 15:22) [15]

> Vuk © (26.12.03 15:08) [14]

На самом деле я просто хотел сказать, что невозможно таким образом написать более-менее полный StoredProc-ориентированный АПИ, с помощью которого потом можно будет лепить любой функционал клиента (в отличие от Win32 API, например). Т.е. если есть две процедуры-выборки из двух разных таблиц, то на их основе нельзя сделать выборку - связку этих двух таблиц. Только писать новую ХР - а это уже изменение функционала АПИ.

← →
Vuk (2003-12-26 15:24) [16]

to Nikolay M.:
>Т.е. если есть две процедуры-выборки из двух разных таблиц, то
>на их основе нельзя сделать выборку - связку этих двух таблиц.
Так никто и не собирался. Назначение такого API - в отвязывании логики клиента от логики хранилища.

← →
Nikolay M. (2003-12-26 15:41) [17]

> Так никто и не собирался.

Это все понятно... Хотя жаль :(

Короче, мысль ясна, спасибо.

← →
Vuk (2003-12-26 15:46) [18]

to Nikolay M.:
Ну, честно говоря, многие процедуры используются во многих местах в клиенте, но, по большей части, это получается за счет архитектуры клиента - существует множество фреймов (это 90% объема проекта), из которых как из кирпичиков строится приложение.

← →
Nikolay M. (2003-12-26 16:02) [19]

> существует множество фреймов (это 90% объема проекта), из
> которых как из кирпичиков строится приложение

Угу, примерно такое "наследство" сейчас и разгребаю - тонна фреймов, дикое наследование классов и форм... Черт ногу сломит :(

← →
Romkin (2003-12-26 16:04) [20]

Фреймы... Я вот их только месяц назад юзать начал... А сейчас сижу, и смотрю... Гораздо лучше мне было вместо иерархии фреймов сделать это все через ActiveXForm :(
И модульно, и как раз полиморфизм, который мне нужен был... И как раз с сервером приложений вполне можно связываться :)))

← →
Vuk (2003-12-26 16:15) [21]

Ну.. Это как строить. У нас получилось не более 3-х уровней наследования для форм. То есть:
TForm->Базовая форма->все остальные формы

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

Я бы не сказал, что все это можно назвать "черт ногу сломит". :o)

← →
Sergey_Masloff (2003-12-26 16:25) [22]

Я тоже больше чем 4 уровня (без TForm - 3) не вижу необходимости. По крайней мере мне таких ситуаций не встречалось.

← →
Romkin (2003-12-26 16:40) [23]

А я и не говорил, что у меня черт ногу сломит :) Просто сделано пара предков-фреймов с необходимыми виртуальными методами, и от них потомки (максимум 2 уровня еще). А форма динамически определяет, какой класс нужен (берет имя из таблицы), и создает нужный фрейм, а потом общается с ним методами общего предка. Полиморфизм, в общем.
Но дело в том, что именно эта конструкция очень легко перекладывается на интерфейсы и коклассы. Так и надо было с самого начала делать. Увы, уже не перепишешь. Сейчас приходится registerClass вызывать, то есть добавление потомка вызывает изменение его пользователя.
Если через интерфейсы, то очень просто: в базе храняться ClassID, по ним просто создаются объекты, причем в отдельных библиотеках.
Получается полностью модульное приложение. И вот тут средний уровень весьма желателен, просто превращаем основной модуль клиента в сервер приложений :))) И остальные модули соединяются с ним (или другими модулями). Все очень красиво, элегантно и легко в сопровождении.
Думаю, попробую именно так скоро.

← →
Romkin (2003-12-26 16:45) [24]

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

← →
Polevi (2003-12-26 18:20) [25]

у меня тут идея написать OPF, объекты описывать XML, их методы VB script"ом, работать под MS Script Control - на midleware и клиенте.. объекты туда сюда в xml, никаких db-aware и dataset.. интересно что получится, если получится - сообщю :-)

← →
Vuk (2003-12-26 18:24) [26]

to Polevi:
А смысл городить это всё?

← →
Polevi (2003-12-26 18:32) [27]

← →
Polevi (2003-12-26 18:34) [28]

к тому же кажется что на это у меня не уйдет много времени, еще есть идея кэшировать объекты.. и много всего всего инетерсеного
инетерсно мне, вот зачем :-)

← →
Vuk (2003-12-26 18:43) [29]

to Polevi:
>а какой смысл в VCL ?
VCL - это, извините, не OPF.
И еще. Как Вы собираетесь OPF с эффективностью работы с данными совмещать?

← →
Polevi (2003-12-26 18:59) [30]

>VCL - это, извините, не OPF.
простите
а насчет эфф. работы с данными - не совсем понял что имеется в виду, если выборки - получать данные от MS SQL сервера буду в xml , постить их также
я так понимаю у вас был некий опыт в этой области, если так - если я пойму что это все не нужно - я вам сообщу персонально

← →
Polevi (2003-12-26 19:02) [31]

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

← →
Vuk (2003-12-26 19:12) [32]

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

← →
Vuk (2003-12-26 19:26) [33]

to Vuk:
>насчет смысла - какой смысл вообще в любой новой технологии если
>есть старые, проверенные временем ?
Скажем так, если новая технология позволяет решать задачи не менее эффективно и с меньшими затратами на разработку, чем старая, то использовать можно. С OPF так не очень-то получается. С .net - надо смотреть, там не одна технология, а целая куча.

← →
Nikolay M. (2003-12-26 19:51) [34]

> зачем к примеру нужен .NET

Кстати, раз уж зашла тема о дотнете: кто-нибудь думал о переходе на дотнет именно на Д8? Лично я не вижу в этом смысла, если есть C# и C++ .Net. Плюс востребованность С#, судя по попе.ру, чуть ли не больше Delphi. Видимо придется мигрировать либо на C#, либо на Java, чего, честно говоря, не очень хочется - теряется опыт как дельфиста.
Все сказанное - имхо, могу в чем-то и ошибаться.

← →
Vuk (2003-12-26 19:56) [35]

Я уже по этому поводу говорил. При наличии Delphi for .net не вижу смысла куда-либо мигрировать. По большому счету, на чем писать под .net - по барабану, но C# не нравится как язык.

← →
Nikolay M. (2003-12-26 20:23) [36]

> Я уже по этому поводу говорил

Не заметил, честно.

> При наличии Delphi for .net не вижу смысла куда-либо мигрировать

Интересно, что будет более востребованно года через 2-3: Д8 или С#? Особенно это интересно, если года через 3 придется заниматься поиском работы. А я лично (пока) сторонник того, что программисту следует менять работу каждые года 2, пока у него идет наработка опыта, поднятие скиллов, освоение новых технологий (хотя этот процесс тоже бесконечен :) ).

Надобность App-server-а при использовании MS SQL - ? Найти похожие ветки