Здравствуйте Thunder, Вы писали:
IT>>Как я понимаю, ты хочешь открыть соединение с базой, понаоткрывать server-side рекорсетов и по мере надобности искать в них данные. Это будет работать до тех пор, пока у тебя в сети 10 пользователей. А если их 1000 и программа каждого постоянно держит не одно соединение, а несколько, да ещё по 10 рекорсетов на каждом? Любой SQL сервер офигеет от этого очень быстро.
T>Ну не скажи зачем же так все усугублять открывать рекордсеты только в режиме редактирования. И я думаю при 1000 пользователях максимум человек 100 может одновременно изменять данные (на практике их гораздо меньше) в основном идет просмотр данных. А в моей системе их всего будет не больше 100.
Понимаешь в чем дело — выборки все равно будут храниться на сервере в памяти. Выигрыш серверных курсоров может быть только в кешировании. А задача кеширования решается сервером приложений на порядок эффективнее. Ну а если курсоры клиентские то все равно даже с ADO вся выборка будет сбрасываться разом и перегружаться при каждом рефреше. Если вспомнить что серверные курсоры появились относительно недавно то я не думаю что при работе с sql-сервером мы получим что то сильно отличное в плане быстродействия от того что было. Просто если раньше процесс получения выборок был автоматическим то в ADO.NET этот процесс можно контролировать.
T>Я собственно почему поднял этот вопрос в VS.NET есть библиотека ADO 2.7 но котролов для ее использования нет.
ADO идет сама по себе. До недавнего времени это была основная библиотека доступа к данным от MS.
T>Может кто работал с этой библиотекой и если да то какие контролы он использовал.
Это зависит от средства разработки. В Дельфи например с ADO работают ее стандартные контролы.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте kig, Вы писали:
IT>>>>>А какой смысл? Новое ADO после адаптационного периода смотрится вполне прилично.
kig>>>>А если на сервере приложений .NET, а на клинетах нет? И только, старое доброе ADO?
AVK>>>Если есть сервер приложений, то зачем ADO на клиенте?
kig>>Предпосылок множество, но все они упираются примерно в следующее:
kig>>1. Отсутствие дотнет на клиенте. AVK>зачем тогда сервер приложений? И как ты его собираешся без дотнета пользовать?
Последнюю фразу двояко можно понять... То ли сервер без дотнета, то ли клиент.
kig>>2. По условиям задачи нет возможности использовать чистого browser-клиента (попробуйте бухгалтера или девочку, которая вводит накладные, затавить работать на browser-клиенте). AVK>Это понятно
kig>>3. Приложения клиента(ов) уже есть, необходимо наименьшими затратами, с одной стороны, сервер приложений перевести на новые технологии, с другой стороны не переписывать (или минимизировать) клиента(ов).
kig>>Конечно, все это трудности переходного периода... AVK>Я боюсь что совместить прямой доступ данных и сервер приложений совместить не получится. Из-за необходимости синхронизации нельзя будет кешировать данные, а при этом весь смысл использования серверов приложений отпадает.
Не идет разговор о прямом доступе. Я же не из головы все это выдумываю. Вот конкретика — есть система, стоящая, так, примерно, у 100 заказчиков. Система построена на многозвенке. В качестве клиента выступает приложение на Д, но общается этот клиент не БД, а с сервером приложений (СП).
И вот появился дотнет. Казалось бы, давайте все перенесем под него. Но проблема в том, что заказчики не пойдут на финансирование полной переделки все системы, и клиентов, и СП. А развивать СП хотелось бы уже в новой технологии. Напрашивается след. решения:
1. Плюнуть на все и оставить все как есть....
2. Параллельно развивать две системы и новым заказчикам представлять уже на новой технологии — это накладно — придется еще и поддерживать 2 системы (и клиентов и СП).
3. Пока, пока идет переходный период с ... на дотнет, в том числе и на клиентах... переписать пока только СП, а клиента только адаптировать на новый стык с СП. И более клиента не трогать. Тем более, что основной процесс переваривания (бизнес-логика) все равно крутиться на СП. И изменения в системе (развитие) ложаться на 95% имено на изменения в СП.
Здравствуйте kig, Вы писали:
kig>1. Плюнуть на все и оставить все как есть.... kig>2. Параллельно развивать две системы и новым заказчикам представлять уже на новой технологии — это накладно — придется еще и поддерживать 2 системы (и клиентов и СП). kig>3. Пока, пока идет переходный период с ... на дотнет, в том числе и на клиентах... переписать пока только СП, а клиента только адаптировать на новый стык с СП. И более клиента не трогать. Тем более, что основной процесс переваривания (бизнес-логика) все равно крутиться на СП. И изменения в системе (развитие) ложаться на 95% имено на изменения в СП.
Ну все правильно в общем то, но при чем здесь ADO на клиенте?
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте kig, Вы писали:
kig>>1. Плюнуть на все и оставить все как есть.... kig>>2. Параллельно развивать две системы и новым заказчикам представлять уже на новой технологии — это накладно — придется еще и поддерживать 2 системы (и клиентов и СП). kig>>3. Пока, пока идет переходный период с ... на дотнет, в том числе и на клиентах... переписать пока только СП, а клиента только адаптировать на новый стык с СП. И более клиента не трогать. Тем более, что основной процесс переваривания (бизнес-логика) все равно крутиться на СП. И изменения в системе (развитие) ложаться на 95% имено на изменения в СП.
AVK>Ну все правильно в общем то, но при чем здесь ADO на клиенте?
Да просто из-за удобства.
Полно приблуд, контролов, особенно в Д, уже заточенных для работы и отображения регулярных структур даннных. Плюс корреляция с НД в сервере БД. На клиента через ADO-поток данные, оттуда — выжимка изменений — обработка на СП бизнес-логикой этих изменений... ну т.д. и т.п.
В принципе, только для этого.
Здравствуйте kig, Вы писали:
kig>Да просто из-за удобства. kig>Полно приблуд, контролов, особенно в Д, уже заточенных для работы и отображения регулярных структур даннных. Плюс корреляция с НД в сервере БД. На клиента через ADO-поток данные, оттуда — выжимка изменений — обработка на СП бизнес-логикой этих изменений... ну т.д. и т.п. kig>В принципе, только для этого.
Т.е. в соотв. с идеологией Дельфей апп сервер работает не с объектами а с рекордсетами? И доступ к данным осуществляется через своего ADO провайдера? Думаю вам все же надо переходить на объектную модель, иначе всех прелестей дотнета вы не поимеете.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте kig, Вы писали:
kig>>Да просто из-за удобства. kig>>Полно приблуд, контролов, особенно в Д, уже заточенных для работы и отображения регулярных структур даннных. Плюс корреляция с НД в сервере БД. На клиента через ADO-поток данные, оттуда — выжимка изменений — обработка на СП бизнес-логикой этих изменений... ну т.д. и т.п. kig>>В принципе, только для этого. AVK>Т.е. в соотв. с идеологией Дельфей апп сервер работает не с объектами а с рекордсетами? И доступ к данным осуществляется через своего ADO провайдера? Думаю вам все же надо переходить на объектную модель, иначе всех прелестей дотнета вы не поимеете.
Сервер работает не с рекордсетами как таковыми, а представляет их ... ну как бы сериализованные данные определенных объетов. По аналогии с дотнетом можно представить себе класс, который рожается от датасета + своя бизнес логика. Ну а сейчас — бизнес-объект, как бы надстройка над ADO-рекордсетом
А для такой, как бы сказать, сериализации, на данном этапе используются адошные возможности. Ну это, конечно в идеале... В некоторых местах идет работа напрямую с рекордсетами ... Ну так уж исторически сложилось. И щас это если и будем переделывать, то только на дотнете.
Свой провайдер мы не используем... нам он не нужен
В будущем, при переходе на дотнет, это то же еще под вопросом останется — гонять между клиентом и сервером свои сериализованные "чистые" объекты, или рожать их уже от датасета.
Здравствуйте kig, Вы писали:
kig>Сервер работает не с рекордсетами как таковыми, а представляет их ... ну как бы сериализованные данные определенных объетов. По аналогии с дотнетом можно представить себе класс, который рожается от датасета + своя бизнес логика. Ну а сейчас — бизнес-объект, как бы надстройка над ADO-рекордсетом
kig>А для такой, как бы сказать, сериализации, на данном этапе используются адошные возможности. Ну это, конечно в идеале... В некоторых местах идет работа напрямую с рекордсетами ... Ну так уж исторически сложилось. И щас это если и будем переделывать, то только на дотнете.
kig>Свой провайдер мы не используем... нам он не нужен
То есть как это? Какого провайдера надо указывать ADO на клиенте?
kig>В будущем, при переходе на дотнет, это то же еще под вопросом останется — гонять между клиентом и сервером свои сериализованные "чистые" объекты, или рожать их уже от датасета.
Я думаю надо это делать сразу а не откладывать на потом.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте kig, Вы писали:
kig>>Сервер работает не с рекордсетами как таковыми, а представляет их ... ну как бы сериализованные данные определенных объетов. По аналогии с дотнетом можно представить себе класс, который рожается от датасета + своя бизнес логика. Ну а сейчас — бизнес-объект, как бы надстройка над ADO-рекордсетом
kig>>А для такой, как бы сказать, сериализации, на данном этапе используются адошные возможности. Ну это, конечно в идеале... В некоторых местах идет работа напрямую с рекордсетами ... Ну так уж исторически сложилось. И щас это если и будем переделывать, то только на дотнете.
kig>>Свой провайдер мы не используем... нам он не нужен
AVK>То есть как это? Какого провайдера надо указывать ADO на клиенте?
Из предыдущего поста
"... И доступ к данным осуществляется через своего ADO провайдера? ... " я это воспринял как собственный OLEDB-провайдер.
Конечно на сервере используется провайдер SQL. На клиенте никаких провайдеров не указывается.
kig>>В будущем, при переходе на дотнет, это то же еще под вопросом останется — гонять между клиентом и сервером свои сериализованные "чистые" объекты, или рожать их уже от датасета. AVK>Я думаю надо это делать сразу а не откладывать на потом.
Здравствуйте kig, Вы писали:
kig>Из предыдущего поста kig>"... И доступ к данным осуществляется через своего ADO провайдера? ... " я это воспринял как собственный OLEDB-провайдер.
Ну правильно ты воспринял
kig>Конечно на сервере используется провайдер SQL. На клиенте никаких провайдеров не указывается.
Нифига опять не понимаю. Как клиент взаимодействует с сервером приложений?
kig>Решить вопрос?
Перейти на объектное представление. А проблему старых клиентов решить написанием собственного IRemotingFormatter. После этого вешаешь стандартного провайдера на один порт, самописного на другой и имеешь доступ и для старых клиентов и для новых.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте kig, Вы писали:
kig>>Из предыдущего поста kig>>"... И доступ к данным осуществляется через своего ADO провайдера? ... " я это воспринял как собственный OLEDB-провайдер. AVK>Ну правильно ты воспринял
А зачем, когда нам щас вполне хватает sql-ного.
kig>>Конечно на сервере используется провайдер SQL. На клиенте никаких провайдеров не указывается. AVK>Нифига опять не понимаю. Как клиент взаимодействует с сервером приложений?
По TCP/IP.
Чего-то я теперь Вас понять не могу. Я же сказал — многозвенка. Клиент вообще не знает, что такое БД и где она и на чем она... и т.д. Клиент общается с аппсервером — вот его он знает. И причем здесь провайдер, который OLEDB?
Или Вы себе представили, что в качестве аппсервера выступает OLEDB-провайдер?
kig>>Решить вопрос? AVK>Перейти на объектное представление. А проблему старых клиентов решить написанием собственного IRemotingFormatter. После этого вешаешь стандартного провайдера на один порт, самописного на другой и имеешь доступ и для старых клиентов и для новых.
Ну это решение, если клиенты будут и новые и старые. Одновременно.
Но я же сказал, не будем мы пока клиентов трогать... будут они старые. Вот для того, что бы форматеры не писать — как гоняли они стримы адощные — так и будут. Ну можно представить, что адошный стрим — частный случай такого форматера.
А по поводу объектного представления — ну на серваке так и есть (почти везде). Или разговор пошел о объктах на клиенте?
Здравствуйте kig, Вы писали:
kig>А зачем, когда нам щас вполне хватает sql-ного.
Т.е. вы эмулируете MSSQL?
kig>По TCP/IP. kig>Чего-то я теперь Вас понять не могу. Я же сказал — многозвенка. Клиент вообще не знает, что такое БД и где она и на чем она... и т.д. Клиент общается с аппсервером — вот его он знает. И причем здесь провайдер, который OLEDB?
Т.е. используется свой собственный протокол? Тогда еще раз — при чем здесь ADO? Трехзвенка это не магическое слово которое все объясняет.
kig>Или Вы себе представили, что в качестве аппсервера выступает OLEDB-провайдер?
Я себе представляю что для доступа к апп серверу используется OLEDB-провайдер. Иного использования ADO в трехзвенных приложениях я не вижу.
AVK>>Перейти на объектное представление. А проблему старых клиентов решить написанием собственного IRemotingFormatter. После этого вешаешь стандартного провайдера на один порт, самописного на другой и имеешь доступ и для старых клиентов и для новых.
kig>Ну это решение, если клиенты будут и новые и старые. Одновременно. kig>Но я же сказал, не будем мы пока клиентов трогать... будут они старые. Вот для того, что бы форматеры не писать — как гоняли они стримы адощные — так и будут.
Что понимается под "гонянием адошных стримов"? Выдергивание готовых рекордсетов по DCOM?
kig> Ну можно представить, что адошный стрим — частный случай такого форматера.
Какой то у вас очень странный сервер приложений. Мне все больше кажется что нужно похерить и переписать по новой — в итоге будет быстрее.
kig>А по поводу объектного представления — ну на серваке так и есть (почти везде). Или разговор пошел о объктах на клиенте?
Прежде всего на сервере. А на клиенте по желанию. Лучше конечно тоже.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте kig, Вы писали:
kig>>А зачем, когда нам щас вполне хватает sql-ного. AVK>Т.е. вы эмулируете MSSQL?
Зачем???? и где??? о чем речь то идет?
kig>>По TCP/IP. kig>>Чего-то я теперь Вас понять не могу. Я же сказал — многозвенка. Клиент вообще не знает, что такое БД и где она и на чем она... и т.д. Клиент общается с аппсервером — вот его он знает. И причем здесь провайдер, который OLEDB? :???: AVK>Т.е. используется свой собственный протокол? Тогда еще раз — при чем здесь ADO? Трехзвенка это не магическое слово которое все объясняет.
Используется протокол тот, который в Борланде. Borland Socket Server.
А адо здесь при одном — мне чего, гриды собственные писать, что бы отображать списки или коллекции в морде клиента? Или еще какие контролы. Оно мне надо? Когда полно db-аварных компонентов, которым начхать, откуда набор данных появился. Из БД скачан, с аппсервера приехал или вообще в памяти создан?
Вот для чего используется ado, в звязке (производное от TАдоDataset) — TDataSource — TDBGrid.. TDBCombj и т.п.
С таким же успехом мы могли бы использовать просто борландовский TClientDataset, но что-то нам подсказало, что не далеко те времена, которые щас наступили. А в дотнете с TClientDataset наверно еще и повозиться придется, и результат этого заранее неопределен.
kig>>Или Вы себе представили, что в качестве аппсервера выступает OLEDB-провайдер? AVK>Я себе представляю что для доступа к апп серверу используется OLEDB-провайдер. Иного использования ADO в трехзвенных приложениях я не вижу.
Это почему не видишь? Только тем, что данные, типа, через провайдер поставляются? А чем отличие, ну например, RDS (remote provider), кроме того, что он провайдером называется, от Borland Socket Server? Наборы данных он чего, святым духом пересылает? Точно так же рекодсеты в виде потоков гонит, или по DCOM, или по HTTP. А вот tcp/ip стыка у него нет, поэтому и не подошел нам.
Тем более, что Борланд уже представляет, пускай другой, но работающтй способ. И мне им не пользоваться, только потому что он выполнен не в виде оledb-провайдера?
Да и по сути — делают они одно и тоже, пока разговор о даныых идет. А вот только возможностей у Борланда перед RDS поболее. Например дернуть объет за метод на серваке RDS не может (на то он и провайдер).
AVK>>>Перейти на объектное представление. А проблему старых клиентов решить написанием собственного IRemotingFormatter. После этого вешаешь стандартного провайдера на один порт, самописного на другой и имеешь доступ и для старых клиентов и для новых.
kig>>Ну это решение, если клиенты будут и новые и старые. Одновременно. kig>>Но я же сказал, не будем мы пока клиентов трогать... будут они старые. Вот для того, что бы форматеры не писать — как гоняли они стримы адощные — так и будут. AVK>Что понимается под "гонянием адошных стримов"? Выдергивание готовых рекордсетов по DCOM?
по tcp/ip
kig>> Ну можно представить, что адошный стрим — частный случай такого форматера. AVK>Какой то у вас очень странный сервер приложений. Мне все больше кажется что нужно похерить и переписать по новой — в итоге будет быстрее.
см. выше да и зачем переписывать, когда работает. И быстро и устойчиво.
kig>>А по поводу объектного представления — ну на серваке так и есть (почти везде). Или разговор пошел о объктах на клиенте? AVK>Прежде всего на сервере. А на клиенте по желанию. Лучше конечно тоже.
Да я уже говорил, что на серваке — это объкты. Дернул метод на апп — получил набор (например). Дернул другой метод на апп — отдал изменения, сделанные в нем. А чего он там с ними делает, клиенту по барабану. Сохраняет куда, делает при этом массовые изменения, связанные с логикой... клиент об этом не задумывается.
Здравствуйте kig, Вы писали:
AVK>>Т.е. используется свой собственный протокол? Тогда еще раз — при чем здесь ADO? Трехзвенка это не магическое слово которое все объясняет. kig>Используется протокол тот, который в Борланде. Borland Socket Server.
Дальше давай. Ну что приходится из тебя вытягивать подробности клещами. Если тебе известно как работает твой софт это совсем не значит что это известно другим.
kig>А адо здесь при одном — мне чего, гриды собственные писать, что бы отображать списки или коллекции в морде клиента? Или еще какие контролы. Оно мне надо? Когда полно db-аварных компонентов, которым начхать, откуда набор данных появился. Из БД скачан, с аппсервера приехал или вообще в памяти создан? kig>Вот для чего используется ado, в звязке (производное от TАдоDataset) — TDataSource — TDBGrid.. TDBCombj и т.п.
А теперь объясни — как борландовский рекордсет после передачи преобразуется в адошный? Борланд поставляет своего провайдера?
kig>>>Или Вы себе представили, что в качестве аппсервера выступает OLEDB-провайдер? AVK>>Я себе представляю что для доступа к апп серверу используется OLEDB-провайдер. Иного использования ADO в трехзвенных приложениях я не вижу.
kig>Это почему не видишь? Только тем, что данные, типа, через провайдер поставляются? А чем отличие, ну например, RDS (remote provider), кроме того, что он провайдером называется, от Borland Socket Server? Наборы данных он чего, святым духом пересылает?
Ты мне объясни — каким духом борландовский протокол преобразуется к ado recordset.
kig>Точно так же рекодсеты в виде потоков гонит, или по DCOM, или по HTTP. А вот tcp/ip стыка у него нет, поэтому и не подошел нам.
У кого, у DCOM? Естественно нет. Он работает по любому протоколу, в том числе и по tcp/ip.
kig>Тем более, что Борланд уже представляет, пускай другой, но работающтй способ. И мне им не пользоваться, только потому что он выполнен не в виде оledb-провайдера?
А как он на самом деле выполнен?
kig>Да и по сути — делают они одно и тоже, пока разговор о даныых идет. А вот только возможностей у Борланда перед RDS поболее. Например дернуть объет за метод на серваке RDS не может (на то он и провайдер).
Ну замечательно все, но ADO то тут при чем? Ты хочешь сказать что борландовский клиент сам по своему протоколу связывается с сервером, затем создает ado recordset и заполняет его полученными данными?
AVK>>Что понимается под "гонянием адошных стримов"? Выдергивание готовых рекордсетов по DCOM? kig>по tcp/ip
По своему протоколу? Ну тогда это полнейший идиотизм. Зачем было прикручивать ado не понятно. Если очень хочется пользовать контролы ориентированные на ADO лучше бы было написать своего провайдера или использовать DCOM или вобще с адо не связываться.
kig>см. выше да и зачем переписывать, когда работает. И быстро и устойчиво.
А зачем тогда дотнет? Потому наверное что хочется чтобы проект развивался. Так? А мешанина из борладновских, старых и новых МС технологий приведет к тому что развиваться вам будет сложно.
AVK>>Прежде всего на сервере. А на клиенте по желанию. Лучше конечно тоже.
kig>Да я уже говорил, что на серваке — это объкты. Дернул метод на апп — получил набор (например). Дернул другой метод на апп — отдал изменения, сделанные в нем. А чего он там с ними делает, клиенту по барабану. Сохраняет куда, делает при этом массовые изменения, связанные с логикой... клиент об этом не задумывается.
А нахрена тогда вобще все эти извращения с ADO и Borland Socket Server? Гоняли бы данные напрямую по tcp и не придумывали бы себе лишних проблем.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте IT, Вы писали:
IT>>ADO.NET вполне нормально вписывается в обновлённую идеологию MS распределённых систем (это моё ИМХО, конечно), которая всё больше ориентируется на stateless системы, как на наиболее надёжные, масштабируемые и менее ресурсоёмкие, и уходит от stateful, у которых есть только одно преимущество — быстродейсвие, которое в свою очередь также быстро заканчивается при увеличении нагрузки на систему.
AVK>Все это правильно, но многие вещи не реализуемы stateless в принципе. Тут несколько другой уклон — state нужно выносить в апп сервер. А вот с sql сервером stateful общение совсем не обязательно.
Из нереализуемых вещей мне известно только кеширование и синхронизация работы части сиситемы. Но кеширование это и не stateless и не stateful, это кеширование А вот синхронизацию на stateless действительно не сделаешь, но опять же, при увеличении нагрузки на систему это станет узким местом.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте AndrewVK, Вы писали:
AVK>Понимаешь в чем дело — выборки все равно будут храниться на сервере в памяти. Выигрыш серверных курсоров может быть только в кешировании. А задача кеширования решается сервером приложений на порядок эффективнее. Ну а если курсоры клиентские то все равно даже с ADO вся выборка будет сбрасываться разом и перегружаться при каждом рефреше. Если вспомнить что серверные курсоры появились относительно недавно то я не думаю что при работе с sql-сервером мы получим что то сильно отличное в плане быстродействия от того что было. Просто если раньше процесс получения выборок был автоматическим то в ADO.NET этот процесс можно контролировать.
Да но мы проигрываем в скорости в системах с небольшим количеством пользователей.
Также в удобстве работы.
Так например зачем пользователю при воде элемента справочника знать его ID.
А грузить его в память не совсем хочется так как он не один и может иметь большой размер.
Загружать данные только при необходимости сильно замедлит работу.
Использовать иерхическую структуру справочников тоже не всегда получается.
T>>Я собственно почему поднял этот вопрос в VS.NET есть библиотека ADO 2.7 но котролов для ее использования нет. AVK>ADO идет сама по себе. До недавнего времени это была основная библиотека доступа к данным от MS.
Я имел в виду что она входит в пакет VS.NET.
T>>Может кто работал с этой библиотекой и если да то какие контролы он использовал. AVK>Это зависит от средства разработки. В Дельфи например с ADO работают ее стандартные контролы.
В Делфи пока с этим проблем вобще нет. Но выход Делфи под .Net ожидается только Осенью.
[skip]
AVK>Дальше давай. Ну что приходится из тебя вытягивать подробности клещами. Если тебе известно как работает твой софт это совсем не значит что это известно другим.
Ладно... давай я все по-порядку. А то опять каша получится. :)) ок? А потом на твои замечания отвечу.
Значит так. Когда все только рождалось (в смысле проект затевался) — ну встали извечные вопросы, на чем, как и т.п. писать. И что бы развиваться можно было, и что бы то развитие по трудозатратам было минимальным.... В то время уже во всю орали про дотнет, не помню правда когда его обещали публике в то время, но этот временной лаг был больший, чем мы могли сидеть и ждать, когда его (дотнет) нам преподнесут.
По многим соображениям, в том числе и сображениям пристрастий, был выбрана Д. (Кстати — по твоим словам в полемике с Владом ты как раз и говорил, что с твоей точки зрения, она занимает неплохую нишу — за точность слов не ручаюсь, на за смысл да). В том числе была выбрана многозвенка.
Что имела Д на тот момент для решений такой архитектуры (кстати — появилось-то это все в Д3.01 — кажется 1997 год).
Во-первых, мидас-технологию. Построение многозвенных систем по стыкам tcp/ip, dcom, corba и http-stateless. Нас интересовал только первый вариант. dcom (по поводу tcp/ip транспорта для dcom я в курсе) — проблемы, которые возникают на файрволах (порты). Ну corba сама по себе не интересовала. Http — за собой надо тащить IIS (правда, кажется еще и апач можно — но не знаю, не уверен).
Во-вторых, свой собственный клиентский датасет — TClientDataset. Набор данных, который даже коннекта к БД не имеет — его там пихнуть даже некуда.
В-третьих. Всякое вспомогательное барохло, типа Borland Server Socket, которое умеет перекладывать вызовы tcp/ip на комовские ну и обратно результаты возвращать и неплохо это делать (по поводу написать самим и т.п. — ну на кой черт, если решение уже есть, исходники тоже — пользуй и правь, если надо).
В-четвертых — ну полным полно всякий разных компонентов, в том числе ДБ-аварных, под Д.
Теперь, откуда на клиенте взялся ADO. Казалось бы, пользуй мидасовский датасет (TClientDataset) на клиенте, и все проблемы решены. Так в начале и планировалось. Но!
О дотнете-те то уже вопят. И как-то сложилось мнение, что когда-нибудь, в не такое уж отдаленное время, придется переползать на нее. И что возможностей там будет ого-го. И вот что-то тогда нам подсказывало, что мидасовского датасета там уж точно не будет. :)) А вот ADO какое-то время будет поддерживаться (т.е. тоже казалось, но с большой долей уверенности :) ). А так хотелось с наименьшими затратами перейти, для начала на серваке, на дотнет... По крайней мере, оставить возможность такого перехода без переписывания клинета. А клиента уже потом поменять... Ведь было понятно, что за одну ночь все на дотнет не перейдут — сами пользователя не перейдут сразу, "за одну ночь" (а насильно у заказчиков их туда толкать ну уж очень не хотелось) — значит на клиентский станциях его какое-то время не будет. Т.е все будет происходить тихим эволюционным путем без всяких революций.
Так вот. Вот тогда и пришли соображения, гонять по мидасу не пакеты TClientDataset, а потоки адошных рекордсетов.
Вот отсюда и появился адо на клиенте.
[skip]
AVK>А теперь объясни — как борландовский рекордсет после передачи преобразуется в адошный? Борланд поставляет своего провайдера?
TAdoDataset в Д уже существует, кажется с 5.0. Это обертка вокруг ADODB. Так что проблем больших нет через ADODB.Stream создавать ADODB.Recorset в TAdoDataset и забирать его оттуда.
AVK>Ты мне объясни — каким духом борландовский протокол преобразуется к ado recordset.
Ну если этот протокол позволяет гонять потоки байтов, то чего там преобразовывать? адошный стрим в адошный рекордсет или обратно. Чего, там большие проблемы? Кстати — а встречный вопрос — а RDS по HTTP чего гоняет — рекордсеты в виде потоков? Ну не интерфейсы же адошные он выставляет :)) :))
AVK>По своему протоколу? Ну тогда это полнейший идиотизм.
А почему протокол, который уже представлен Борландом, это обязательно идиотизм?
AVK>Зачем было прикручивать ado не понятно. Если очень хочется пользовать контролы ориентированные на ADO лучше бы было написать своего провайдера или использовать DCOM или вобще с адо не связываться.
Про адо уже сказал.
AVK>Если очень хочется пользовать контролы ориентированные на ADO лучше бы было написать своего провайдера или использовать DCOM или вобще с адо не связываться.
На кой мне черт сдался провайдер? Свой собственный? Который мне еще и писать надо? И при чем здесь контролы, ориентированные на адо? В Д. дб-аварные контролы ориентированы на TDataSet. И он абстрактный. А уж от него — и bde-ешные, и адошные. Да и TClientDataset...
По поводу DCOM — ага — и открывать tcp/ip порты DCOM корпоративной сети на публику в инет.
Еклмн... ну у тебя так — если адо и его пользовать — то это обязательно провайдер для него.
А если я тот же результат получаю меньшими усилиями (писать не надо) — но это не oledb-провайдер — это уже идиотизм? Тем более, что у меня там прекрасная возможность общаться с обектами на апп и дергать их за методы, которые к данным не имеют ни какого отношеня (т.е. не возвращаю наборы данных на клиента и не принимают наборы данных от него).
Здравствуйте kig, Вы писали:
AVK>>А теперь объясни — как борландовский рекордсет после передачи преобразуется в адошный? Борланд поставляет своего провайдера?
kig>TAdoDataset в Д уже существует, кажется с 5.0. Это обертка вокруг ADODB. Так что проблем больших нет через ADODB.Stream создавать ADODB.Recorset в TAdoDataset и забирать его оттуда.
Вот теперь понятно. Надо было с этого начинать. Dataset там кстати появился далеко не с первых версий.
AVK>>По своему протоколу? Ну тогда это полнейший идиотизм. kig>А почему протокол, который уже представлен Борландом, это обязательно идиотизм?
Да нет, я просто только теперь понял как дело обстоит.
AVK>>Если очень хочется пользовать контролы ориентированные на ADO лучше бы было написать своего провайдера или использовать DCOM или вобще с адо не связываться. kig>На кой мне черт сдался провайдер? Свой собственный? Который мне еще и писать надо?
Прозрачно для клиента.
kig> И при чем здесь контролы, ориентированные на адо? В Д. дб-аварные контролы ориентированы на TDataSet. И он абстрактный. А уж от него — и bde-ешные, и адошные. Да и TClientDataset... kig>По поводу DCOM — ага — и открывать tcp/ip порты DCOM корпоративной сети на публику в инет.
Ну откуда я знаю что у тебя клиенты снаружи?
kig>Еклмн... ну у тебя так — если адо и его пользовать — то это обязательно провайдер для него.
Да нет конечно. Просто датасет там появился относительно недавно, когда я уже под адо почти ничего серьезного не писал и я как то сразу про него не подумал.
Здравствуйте IT, Вы писали:
IT>Из нереализуемых вещей мне известно только кеширование и синхронизация работы части сиситемы. Но кеширование это и не stateless и не stateful, это кеширование А вот синхронизацию на stateless действительно не сделаешь, но опять же, при увеличении нагрузки на систему это станет узким местом.
Stateful нужен если нужны session scope объекты на сервере.
Здравствуйте AndrewVK, Вы писали:
AVK>Вот теперь понятно. Надо было с этого начинать. Dataset там кстати появился далеко не с первых версий.
Да... наверно сумбурно все с самого начала объяснял.
Да dataset был еще в 1.0. Вот только в 3.0 они оторвали его от BDE, чем облегчили жисть не только себе, но и нам А адошный, кажется с 5.
[skip]
AVK>Прозрачно для клиента.
Ну вот теперь я думаю, в морде лица клиента можно будет дергание за Борланда заменить на дергание за WebService через SOAP toolkit. Ессно с поправкой на stateless (хотя мы сразу особенно на statefull на клиенте не цеплялись, ну кроме того, что коннект тсп-ишный был постоянный).
AVK>Ну откуда я знаю что у тебя клиенты снаружи?
Здравствуйте Thunder, Вы писали:
T>Да но мы проигрываем в скорости в системах с небольшим количеством пользователей.
На файловой базе.
T>Также в удобстве работы. T>Так например зачем пользователю при воде элемента справочника знать его ID.
А вот тут совсем не понял — пользователь то тут при чем? Скорее пользователю наоборот удобнее, поскольку зная заранее размер выборки можно сделать скроллеры отражающие реальное положение вещей. А зачем ему знать id я честно говоря не понял.
T>А грузить его в память не совсем хочется так как он не один и может иметь большой размер. T>Загружать данные только при необходимости сильно замедлит работу.
Видишь ли какое дело — все равно, если ты не используешь сервернеые курсоры то выборку надо держать на локальной машине. Так что ado.net ничего тут не меняет. Ну а если память жалко — тогда скидывай из datareader не в dataset а на диск, и подгружай по мере необходимости.
T>Использовать иерхическую структуру справочников тоже не всегда получается.
Тем не менее практика показывает что можно обойтись без загрузки огромных массивов данных на клиента. Причина проста — ни один человек все равно не в состоянии воспринять за один раз больше 2-3 килобайт информации. Большие выборки нужны только для автоматической обработки (подготовка отчетов, проводки). А это можно и нужно делать на сервере приложений.
T>Я имел в виду что она входит в пакет VS.NET.
Не входит. Просто нужна для работы.
И только, старое доброе ADO?
Если нам не помогут, то мы тоже никого не пощадим.
