информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Портрет посетителяСтрашный баг в WindowsВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[C++] Наверное, я плохо задал вопрос. 08.09.03 04:19  Число просмотров: 1377
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Спасибо, что откликнулись. Ещё раз убеждаюсь, что данный форум – самый лучший на сегодняшний день.

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

1) Так я не понял, Вы этим замечанием поддерживаете моё скромное предложение о том, что в ТЗ следует нацелить СТОРОННИХ ПРОГРАММЕРОВ на использование ТОЛЬКО специализированного API нашей ИС, или нет?

Выше, в «резюме» я просил совета – разумно, или нет в ТЗ предложить СТОРОННИМ РАЗРАБОТЧИКАМ использовать ТОЛЬКО НАШЕ API. Хорошо, что Вы написали про мидлварные решения, но с точки зрения СТОРОННЕГО прикладного программиста (который за тысячи километров от нас будет реализовывать нашу ИС) – это и будет использование нашего API. Смотрите, в своём приложении прикладной программер, например, будет писать строчки (это из работающего кода-«модели»):

Dim hr As Long ' код результата запроса
Dm I As Integer

hr = QueryOpen(hQuery, "select id from tbl1") ' выполняем запрос

If (hr <> S_OK) Then
MsgBox ("Can't open query")
Exit Sub
End If

QueryFirst (hQuery) ' указатель на первую запись
While (QueryEof(hQuery) = False)
I = vbQueryIntegerField(hQuery, "id") ' получаем данные текущей записи


QueryNext (hQuery) ' указатель на следующую запись
Wend

QueryFreeConnections (hQuery) ' удаляем временные объекты
QueryClose (hQuery) ' закрываем активный набор данных

Здесь нет вызовов методов объектов мелкософта или Борланда. Здесь используется один из вариантов API, о котором я писал. Так вот, ну какая разница с точки зрения прикладного программера КАК БУДУТ РЕАЛИЗОВАНЫ эти методы. Для него нет разницы будут ли это фактически вызовами lpc или это маршалинг с удалённого хоста (middleware-сервера). На компе программера (а в последующем юзера) будет установлена некая клиентская прога (API), которая как её напишешь, так она и будет ФАКТИЧЕСКИ реализовывать вызовы. Для прикладного программера это и есть высокоуровневое API нашей ИС. Это API, поскольку это чёрный ящик для прикладного программера, который знает только интерфейс к ящику.


2) Своим не очень программистским умом я всё же думаю, что не следует переоценивать возможности middleware-архитектуры даже для таких случаев, как наш, когда всё можно заорганизовать в единой ведомственной ИС. Надо сказать, что такой мидлварный сервер (то, что вы называете сервером приложений, если я правильно Вас понял) я давно написал в качестве макета, приложения к проекту ТЗ на пректирование ИС. Правда реализован он не корбой, а декомом (у меня есть соображения, почему в нашей СЕТЕВОЙ ИНФРАСТРУКТУРЕ отъявленный мелкософт лучше). Там вызовы такие:

hr = IQuery.Open("select id from tbl1") ' выполняем запрос

If (hr <> S_OK) Then
MsgBox ("Can't open query" & Chr(13) & IQuery.ErrorMessage)
Exit Sub
End If

IQuery.First ' указатель не первую запись
While (IQuery.IsEof = False)
Id = IQuery.IntegerField("id")


IQuery.Next ' указатель на следующую запись
Wend
IQuery.FreeConnections ' удаляем временные объекты соединения с базой данных
IQuery.Close ' закрываем активные наборы данных

Да, конечно, это кул в том смысле, что клиент-«супертонкий». Реализация объектов доступа к данным лежит на мидлаврном сервере. Там и BDE, и ODBC вместе с OLE дебюми в одном флаконе (вернее там, то, что нужно мидлварному серверу компонент доступа к данным в зависимости от его текущей конфигурации). Однако было бы чрезвычайной наглостью навязывать СТОРОННИМ программерам только какую либо реализацию ( пусть и достойную ) архитектуры мидлваре. Лучше ему навязать API, имхо, которое будет инкапсулировать всё, что угодно. Здесь мы имеем больше манёвра, т.к. всегда сможем переписать API так, как нам надо. Сегодня под декомом, завтра под корбой.


3) Это некое дополнение к п. 2. Разумеется мы используем чисто мидлварные решения ОДНОЗНАЧНО ТАМ, ГДЕ ЭТО И НАДО. Например, у нас есть проект некого унифицированного каталога объектов, API которого позволяет делать вызовы типа:

“get object=*,class = месторождения” (запрос прикладного уровня)

Далее это транслируется сервером приложений в строчку типа:

“ select * from sys_object where sys_object.id in (select Obj.Id from sys_Object Obj, sys_Back Bck where Obj.IdClass = Bck.ThisClass and Bck.Parent = 5)”

Далее это отдаётся на съедение драйверам СУБД.

Заметьте, что в этом случае сервер приложений просто необходим, если мы раздаём работу сторонним программерам направо и налево, по написанию неких отчётов, форм и т.д, т.е. всего того, что обычно в немеренном количестве сопровождает приложения баз данных. Необходим, потому что драйвера СУБД знают про SQL, но не знают про прикладной протокол “get object=*,class =…..


4) Сравните код в п.1 (lpc) и п.2.(middleware). С точки зрения прикладного программиста, по большому счёту - ВСЁ ОДИНАКОВО. И в одном и в другом случае он использует методы чёрного ящика – API. Так яж об этом и писал в первом посте.


*****
>>причем велосипед ака сервер приложений можно не избобретать, а, например, взять в качестве >>него EAS от Sybase.
>>Приложения будут общаться с ним через CORBA (или как-то еще), на нем будут крутиться java >>beans, которые через JDBC будут работать с базами данных.

Здесь я Вас не понял. Про велосипед это понятно. Согласен. Но ведь современные средства программирования позволяют, как справедливо отметил один из авторов COM, «штамповать COM/DCOM сервера, как макароны». Для этого не надо даже понимать, что происходит «внутри», да и вообще быть сколь нибудь заметным программистом. Так, что мелкософт постарался здесь, как никогда хорошо. Поэтому мне легче дружить с мелкософтом при разработке мидлварных решений чем с «EAS от Sybase».



*****
>>PS. совет - выбирайте такие СУБД, которые поддерживают хранимые пр-ры, при грамотном >>использовании сэкономите массу времени.

Да, спасибо за совет. То, что хранимые процедуры В ПРИНЦИПЕ это хорошо – ну ктож с этим будет спорить. Да и потом, почему только процедуры? Я бы сказал по другому – надо выбирать те сервера, которые умеют сами делать массу полезной работы и при этом предоставляют прикладному программисту соответствующий командный интерфейс. Например, современные сервера умеют кроме процедур выполнять и функции и удалённо выполнять всяческие джобы и т.д. Про просмотры я вообще уже не говорю.


*****
>>а MS Access выкиньте ан помойку как можно раньше:)

Просто забыть про MS Access невозможно. Как невозможно забыть FoxPro 2.5 в отделах автоматизации многих банков (в России). Там можно делать только то, что дозволено. Иначе уволят, если будешь «усовершенствовать». У нас ситуация не такая зверская, но всёже есть случаи, когда «министерские» базы навязываются только в MS Access. Никуда не денешься.
Правда, навязывают только для «экспортных» баз в качестве транспортного формата. Эти базы периодически сливаются в министерство. Ну, да беда даже не в MS Access. Видели бы Вы структуру тех баз…
Как я писал, наша ИС состоит из ~ 10 относительно независимых баз. То, что можно переложить из MS Access на SQL сервер – перекладываем.

Здесь хочу заметить другое. Моя практика эксплуатации ведомственных систем, написанных средствами Access-a (министерскими и околоминистерскими программерами) показывает, что ГЛАВНОЕ ЗЛО MS ACCESS НЕ В ВОЗМОЖНОСТЯХ JET ИЛИ КАКОГО-НИБУДЬ ДРАЙВЕРА, А ТЕХ ВСТРОЕННЫХ ВОЗМОЖНОСТЯХ РИСО-ПРОГРАММИРОВАНИЯ, КОТОРЫЕ ТАМ ЕСТЬ.
Разумеется, это касается только приложений для сетевого многопользовательского доступа.


PS.

1) Вы так и не ответили на мой вопрос. Разумно, или не разумно набраться нам наглости, и «забить» в ТЗ ОБЯЗАТЕЛЬНОЕ ТРЕБОВАНИЕ для подрядчиков-программистов использовать только НАШЕ API, а не то, к чему он уже привык.
Вопрос не праздный. Это некая наглость, диктат по отношению к программерам, поскольку во многом связывает им руки.

2) Что касается собственно отдельно взятого меня, то лично для меня вопроса нет. Когда я программирую в Борланде, у меня нет в проекте ни одного ихнего компонента доступа к данным. Т.е., ни в статике, ни в динамике не создаются и не используются компоненты типа TQuery и им подобные. Все только через API. Там есть и Query и не только.

Когда я программирую в MSVC, то в С++ коде нигде нет объявлений CDatabase, нет использования низкоуровневого API ODBC, нигде нет даже упоминания об ADO. Всё работает, как и в случае Борланда только через API.
Однако всё это касается только моей собственной персоны. Здесь я сам себе хозяин. Вопрос же топика был в другом. Стоит или нет навязывать другим то, что используешь сам? Да ещё в виде обязательных требований ТЗ.
<programming>
[C++] API или не API? Вот в чём вопрос. 07.09.03 08:01  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Уважаемые Господа.
Мне необходим Ваш совет в части архитектуры приложений баз данных. Не откажите, пожалуйста. Сразу говорю. Я не программист. Так, что могу сильно ошибаться. Если ниже, что не так сказал, не сердитесь.

В моём учреждении разрабатывается техническое задание (ТЗ) на создание информационной системы (ИС). В ТЗ мы формулируем «что нам надо, и как нам надо». Проектировать и реализовывать эту систему будут сторонние разработчики, поскольку мы – не программисты.

ИС – могутная. Разработка предполагается поэтапной (1-2 года). На каждом этапе, возможно, будут трудиться параллельно несколько фирм-разработчиков, реализующие отдельные составляющие ИС.

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

В общих чертах, параметры БД ИС следующие:
- количество БД 7-10;
- часть из этих БД уже расположены на наших SQL серверах (мелкософт), часть лежит в зашаренных папках в MS Access – е;
- число клиентских хостов ~100-200.
- сценарий обновления БД – крайне оптимистический.
- сетка fast Ethernet, TCP/IP.
- серверы и рабочки – окошки.

Предполагается, что на разных этапах разработки для разных БД разные подрядчики могут использовать любые языки программирования приложений (одни конторы будут писать на VB, другие Delphi или BCB++, третьи – MSVC++).

Сложность в том, что на стадии разработки ТЗ мы не можем сделать предположений относительно СУБД, которые могут изменяться при модернизации нашей ИС. Как впрочем, и относительно версий окошек рабочек и серверов и сетевой инфраструктуры. Т.е. сегодня у нас MS SQL Server, а «завтра», возможно мы переедем на оракл или db/2. Вопросы переноса данных с одной СУБД на другую СУБД при модернизации ИС не рассматриваются. Это наша забота. К сторонним программистам предъявляется только одно требование – их клиентское ПО должно «жить» с новыми источниками данных без перекомпиляции. Это требование для нас важно.

Как я сказал выше, основной вопрос – надобно, или нет включать в ТЗ наши специальные требования по методам доступа к данным? Может в договоре с подрядчиком просто оговорить, что их клиентское ПО должно «жить независимо от СУБД»? Мои сомнения относительно «просто строчки в договоре» в том, что:
- это может остаться только декларацией (невыполнимой даже на 50 %). Ниже я приведу свои соображения в этой части;
- подрядчик может согласиться на эту «строчку», но фактически не станет реализовывать в своих проектах СУБД-независимые архитектурные решения.


*ОБЪЕКТЫ ДОСТУПА К ДАННЫМ**

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

BDE
Здесь, на мой взгляд, больше иллюзия «независимости приложения от СУБД», чем её реализация на сегодняшний день. Когда-то - это было кул, но не сегодня. Уже начиная с версии Delphi 5.0 в отличие от 3.0 (тоже, разумеется, касается и BCB++) я к удивлению обнаружил, что native SQL Links драйвера MSACCESS уже не работают, по тому, что мелкософт чего-то не поделил с Борландом. Поддержка компонентами Борланда ODBC-сокетов вообще дубовая (по сравнению с тем, если это делать в VC++ хотя бы с использованием MFC). Не факт что у Борланда найдутся «работающие», а не просто продекларированные native драйвера SQL Links для некой новой версии Oracle, на которую возможно мы переедем в будущем.
Таким образом, приложение, написанное для нашего предприятия на BCB++ с использованием BDE может уже через год не работать, так как для нашей новой СУБД (установленной при модернизации ИС) нет подходящего native драйвера Борланда.

ODBC
Это более привлекательно по сравнению с BDE. Ясно, что никто не должен Борланду, но все должны мелкософту. Если уж вышла новая версия некого SQL сервера, то уж естественно его разработчики постарались с драйверами ODBC (иначе, как ЭТО будет юзастья под окошками старыми клиентами с доступом к данным по ODBC). Мой опыт показывает, что приложения работают устойчиво, если ЭТО программировать средствами VC++ а не использовать сокеты компонент Борланда. Опасения в части ODBC только такие, что производители серверного софта могут решить, что хватит постоянно реанимировать архаичные технологии доступа к данным, и что, для того чтобы их SQL сервер был самым SQL сервером в мире, следует использовать только ихние сверхпроизводительные OLE DB компоненты. Доля шутки в этой шутке в том, что мелкософт, как мне кажется, давно рассматривает ODBC как устаревший способ доступа к данным, хотя и тянет это API от операционки к операционке для продления жизни старого клиентского софта.

ADO
Наверное, это наименьшее зло из того, что выше. Сомнения только в том, что, не смотря на все заверения мелкософта, настоящим стандартом, на мой взгляд, ЭТО так и не стало (здесь я могу сильно ошибаться). Достаточно посмотреть, что теперь уже ADO не модно. Теперь правильное программирование - только с использованием ADO.NET. Мелкософт заверяет, что, мол, не волнуйтесь, будет, будет поддерживаться ADO вместе с ADO.NET в будущем. Но что-то сильно напоминает соотношение ODBC-ADO.
Кроме того, здесь тоже присутствует некая доля иллюзии «стандартности». Ясно, что в ASCII коде программы разработчик будет использовать действительно стандартный интерфейс к методам компонент ADO. Это радует. Но то, что его скомпилированная программа будет использовать вполне конкретную версию компонент MDAC – это может, на мой взгляд, в будущем принести огорчения. Впрочем, у меня есть практический опыт таких огорчений, когда мы так и не смогли под W98 полноценно прикрутить MDAC для комплекса «АКСИОК» (это могутный комплекс для госконтор. Не помню кто разработчик). Возможно, это было из моей криворукости, вернее криворукости моих сотрудников. Но факт- под W2k и XP работает на ура, а под W98 – через пень-колоду. Динамичность, с которой мелкософт развивает OLE DB просто пугающая. Поэтому и сомнительно, как это будет работать, когда мы переедем на новые версии окошек, где старая версия ADO поддерживается не в полной мере, или для новой версии SQL сервера старый провайдер («зашитый» в коде клиентского ПО) уже не поддерживается. Думаю, без перекомпиляции клиентской проги в этом случае не обойтись. Этого как раз и хочется избежать для нашей ИС. Повторяю, что я считаю ADO лучшим в части построения «живучих» программ. Выше я только о своих сомнениях, которые, возможно, из-за моей малограмотности.


*МЕТОДЫ ДОСТУПА К ДАННЫМ**

Положим, что в результате обсуждения на этом форуме мне объяснили мою дремучесть и невежество и рассеяли все сомнения относительно вышесказанного. Подсказали, что, мол, «забивай» в ТЗ требование – использовать только ADO. Спорно – хорошо ли. Боюсь, наше учреждение в этом случае может потерять в качестве потенциальных разработчиков тех программеров, которые не знакомы с ADO, или по какой-то причине его ненавидят.

Однако есть другой ряд причин, по которым даже использование ADO может не обеспечить требуемой «живучести» приложений нашей ИС, имхо. Программер использует вполне определённый синтаксис SQL. Разработчики всех промышленных СУБД декларируют, что поддерживают стандарт ANSI SQL. Мой опыт показывает, что не факт. Диалекты SQL, например, T-SQL для MSSQL Server, JET-SQL для MSAccess, SQL для SQL Links – различаются как в части синтаксиса DDL, так и DML (например, в определении скалярных функций преобразования типов данных). Конечно, можно в ТЗ ограничить программистов обязательством использовать только, действительно стандартные лексемы и, например, не использовать скалярные функции SQL вообще. Не факт, что программер будет придерживаться этого правила. Да это может быть и не удобным (почти всегда). Например, программер «зашивает» в код функцию cast в предложении select, тогда как после модернизации мы переехали на СУБД, драйверы которой понимают ключевое слово convert вместо cast. Программер «зашивает» в коде строчку ucase, тогда как после модернизации мы переедем на источник данных, драйверам которого надо будет говорить upper вместо ucase. С DDL – ещё хуже (хотя это обычно не критично для клиентской проги).

Поскольку с этими проблемами непереносимости диалектов SQL я сталкивался не раз при решении задач адаптации клиентской проги для работы с различными СУБД, то есть понимание, что ЭТО нельзя оставлять «на самотёк» в ТЗ. Я проблему решал в своё время, как мне казалось, просто. Все SQL запросы вначале отправлялись на претрансляцию. Там в зависимости от драйверов конкретного источника данных выполнялась «корректировка» лексем. Только после этого строка SQL отправлялась драйверу в том виде, в котором он эту строку понимает. Модули претрасляции выполнями «корректировку», пользуясь мапингом в «настроечных» ASCII-файлах (так я делаю сейчас), или в подключаемых dll (так я делал раньше).


*** РЕЗЮМЕ*
Вот теперь я и думаю, и Вас прошу подсказать – поскольку, как мне кажется, существует две проблемы (объекты и методы доступа к данным), то может вообще разумно написать своё API, которое одним махом решало бы эти проблемы. Такое API можно было бы сделать «ведомственным стандартом» по методам доступа ТОЛЬКО ДЛЯ НАШЕЙ ИС. В техзадание тогда можно было бы забить обязательство программистов (подрядчиков) использовать только это API. В коде клиентского ПО – ни каких вызовов мелкософтовского API или борландовских компонент. Используем только своё, самостийное API. Ясно, что такое API инкапсулировало бы объекты мелкософта или борланда (или и то и другое). Т.е. это было бы API классов-обёрток.
В чём преимущество? Что это даёт? То, что такое API можно перекомпилировать при необходимости по десять раз в день, не нарушая работу клиенской проги нашей ИС. Придёт время в процессе модернизации ИС переписать это API для некого нового источника данных – это сможет сделать программер сравнительно невысокой квалификации. Даже я. Перекомпиляция клиентов не нужна вовсе.

Как думаете?
имхо, типичный случай, когда нужно подумать о трехзвенной архитектуре 07.09.03 13:41  
Автор: йцукенг <jcukeng> Статус: Member
<"чистая" ссылка>
имхо, типичный случай, когда нужно подумать о трехзвенной архитектуре.
в инете можно найти кучу инфы о том что это такое, поэтому объяснять подробно не стану.

причем велосипед ака сервер приложений можно не избобретать, а, например, взять в качестве него EAS от Sybase.
Приложения будут общаться с ним через CORBA (или как-то еще), на нем будут крутиться java beans, которые через JDBC будут работать с базами данных.

PS. совет - выбирайте такие СУБД, которые поддерживают хранимые пр-ры, при грамотном использовании сэкономите массу времени.
а MS Access выкиньте ан помойку как можно раньше:)
[C++] Наверное, я плохо задал вопрос. 08.09.03 04:19  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Спасибо, что откликнулись. Ещё раз убеждаюсь, что данный форум – самый лучший на сегодняшний день.

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

1) Так я не понял, Вы этим замечанием поддерживаете моё скромное предложение о том, что в ТЗ следует нацелить СТОРОННИХ ПРОГРАММЕРОВ на использование ТОЛЬКО специализированного API нашей ИС, или нет?

Выше, в «резюме» я просил совета – разумно, или нет в ТЗ предложить СТОРОННИМ РАЗРАБОТЧИКАМ использовать ТОЛЬКО НАШЕ API. Хорошо, что Вы написали про мидлварные решения, но с точки зрения СТОРОННЕГО прикладного программиста (который за тысячи километров от нас будет реализовывать нашу ИС) – это и будет использование нашего API. Смотрите, в своём приложении прикладной программер, например, будет писать строчки (это из работающего кода-«модели»):

Dim hr As Long ' код результата запроса
Dm I As Integer

hr = QueryOpen(hQuery, "select id from tbl1") ' выполняем запрос

If (hr <> S_OK) Then
MsgBox ("Can't open query")
Exit Sub
End If

QueryFirst (hQuery) ' указатель на первую запись
While (QueryEof(hQuery) = False)
I = vbQueryIntegerField(hQuery, "id") ' получаем данные текущей записи


QueryNext (hQuery) ' указатель на следующую запись
Wend

QueryFreeConnections (hQuery) ' удаляем временные объекты
QueryClose (hQuery) ' закрываем активный набор данных

Здесь нет вызовов методов объектов мелкософта или Борланда. Здесь используется один из вариантов API, о котором я писал. Так вот, ну какая разница с точки зрения прикладного программера КАК БУДУТ РЕАЛИЗОВАНЫ эти методы. Для него нет разницы будут ли это фактически вызовами lpc или это маршалинг с удалённого хоста (middleware-сервера). На компе программера (а в последующем юзера) будет установлена некая клиентская прога (API), которая как её напишешь, так она и будет ФАКТИЧЕСКИ реализовывать вызовы. Для прикладного программера это и есть высокоуровневое API нашей ИС. Это API, поскольку это чёрный ящик для прикладного программера, который знает только интерфейс к ящику.


2) Своим не очень программистским умом я всё же думаю, что не следует переоценивать возможности middleware-архитектуры даже для таких случаев, как наш, когда всё можно заорганизовать в единой ведомственной ИС. Надо сказать, что такой мидлварный сервер (то, что вы называете сервером приложений, если я правильно Вас понял) я давно написал в качестве макета, приложения к проекту ТЗ на пректирование ИС. Правда реализован он не корбой, а декомом (у меня есть соображения, почему в нашей СЕТЕВОЙ ИНФРАСТРУКТУРЕ отъявленный мелкософт лучше). Там вызовы такие:

hr = IQuery.Open("select id from tbl1") ' выполняем запрос

If (hr <> S_OK) Then
MsgBox ("Can't open query" & Chr(13) & IQuery.ErrorMessage)
Exit Sub
End If

IQuery.First ' указатель не первую запись
While (IQuery.IsEof = False)
Id = IQuery.IntegerField("id")


IQuery.Next ' указатель на следующую запись
Wend
IQuery.FreeConnections ' удаляем временные объекты соединения с базой данных
IQuery.Close ' закрываем активные наборы данных

Да, конечно, это кул в том смысле, что клиент-«супертонкий». Реализация объектов доступа к данным лежит на мидлаврном сервере. Там и BDE, и ODBC вместе с OLE дебюми в одном флаконе (вернее там, то, что нужно мидлварному серверу компонент доступа к данным в зависимости от его текущей конфигурации). Однако было бы чрезвычайной наглостью навязывать СТОРОННИМ программерам только какую либо реализацию ( пусть и достойную ) архитектуры мидлваре. Лучше ему навязать API, имхо, которое будет инкапсулировать всё, что угодно. Здесь мы имеем больше манёвра, т.к. всегда сможем переписать API так, как нам надо. Сегодня под декомом, завтра под корбой.


3) Это некое дополнение к п. 2. Разумеется мы используем чисто мидлварные решения ОДНОЗНАЧНО ТАМ, ГДЕ ЭТО И НАДО. Например, у нас есть проект некого унифицированного каталога объектов, API которого позволяет делать вызовы типа:

“get object=*,class = месторождения” (запрос прикладного уровня)

Далее это транслируется сервером приложений в строчку типа:

“ select * from sys_object where sys_object.id in (select Obj.Id from sys_Object Obj, sys_Back Bck where Obj.IdClass = Bck.ThisClass and Bck.Parent = 5)”

Далее это отдаётся на съедение драйверам СУБД.

Заметьте, что в этом случае сервер приложений просто необходим, если мы раздаём работу сторонним программерам направо и налево, по написанию неких отчётов, форм и т.д, т.е. всего того, что обычно в немеренном количестве сопровождает приложения баз данных. Необходим, потому что драйвера СУБД знают про SQL, но не знают про прикладной протокол “get object=*,class =…..


4) Сравните код в п.1 (lpc) и п.2.(middleware). С точки зрения прикладного программиста, по большому счёту - ВСЁ ОДИНАКОВО. И в одном и в другом случае он использует методы чёрного ящика – API. Так яж об этом и писал в первом посте.


*****
>>причем велосипед ака сервер приложений можно не избобретать, а, например, взять в качестве >>него EAS от Sybase.
>>Приложения будут общаться с ним через CORBA (или как-то еще), на нем будут крутиться java >>beans, которые через JDBC будут работать с базами данных.

Здесь я Вас не понял. Про велосипед это понятно. Согласен. Но ведь современные средства программирования позволяют, как справедливо отметил один из авторов COM, «штамповать COM/DCOM сервера, как макароны». Для этого не надо даже понимать, что происходит «внутри», да и вообще быть сколь нибудь заметным программистом. Так, что мелкософт постарался здесь, как никогда хорошо. Поэтому мне легче дружить с мелкософтом при разработке мидлварных решений чем с «EAS от Sybase».



*****
>>PS. совет - выбирайте такие СУБД, которые поддерживают хранимые пр-ры, при грамотном >>использовании сэкономите массу времени.

Да, спасибо за совет. То, что хранимые процедуры В ПРИНЦИПЕ это хорошо – ну ктож с этим будет спорить. Да и потом, почему только процедуры? Я бы сказал по другому – надо выбирать те сервера, которые умеют сами делать массу полезной работы и при этом предоставляют прикладному программисту соответствующий командный интерфейс. Например, современные сервера умеют кроме процедур выполнять и функции и удалённо выполнять всяческие джобы и т.д. Про просмотры я вообще уже не говорю.


*****
>>а MS Access выкиньте ан помойку как можно раньше:)

Просто забыть про MS Access невозможно. Как невозможно забыть FoxPro 2.5 в отделах автоматизации многих банков (в России). Там можно делать только то, что дозволено. Иначе уволят, если будешь «усовершенствовать». У нас ситуация не такая зверская, но всёже есть случаи, когда «министерские» базы навязываются только в MS Access. Никуда не денешься.
Правда, навязывают только для «экспортных» баз в качестве транспортного формата. Эти базы периодически сливаются в министерство. Ну, да беда даже не в MS Access. Видели бы Вы структуру тех баз…
Как я писал, наша ИС состоит из ~ 10 относительно независимых баз. То, что можно переложить из MS Access на SQL сервер – перекладываем.

Здесь хочу заметить другое. Моя практика эксплуатации ведомственных систем, написанных средствами Access-a (министерскими и околоминистерскими программерами) показывает, что ГЛАВНОЕ ЗЛО MS ACCESS НЕ В ВОЗМОЖНОСТЯХ JET ИЛИ КАКОГО-НИБУДЬ ДРАЙВЕРА, А ТЕХ ВСТРОЕННЫХ ВОЗМОЖНОСТЯХ РИСО-ПРОГРАММИРОВАНИЯ, КОТОРЫЕ ТАМ ЕСТЬ.
Разумеется, это касается только приложений для сетевого многопользовательского доступа.


PS.

1) Вы так и не ответили на мой вопрос. Разумно, или не разумно набраться нам наглости, и «забить» в ТЗ ОБЯЗАТЕЛЬНОЕ ТРЕБОВАНИЕ для подрядчиков-программистов использовать только НАШЕ API, а не то, к чему он уже привык.
Вопрос не праздный. Это некая наглость, диктат по отношению к программерам, поскольку во многом связывает им руки.

2) Что касается собственно отдельно взятого меня, то лично для меня вопроса нет. Когда я программирую в Борланде, у меня нет в проекте ни одного ихнего компонента доступа к данным. Т.е., ни в статике, ни в динамике не создаются и не используются компоненты типа TQuery и им подобные. Все только через API. Там есть и Query и не только.

Когда я программирую в MSVC, то в С++ коде нигде нет объявлений CDatabase, нет использования низкоуровневого API ODBC, нигде нет даже упоминания об ADO. Всё работает, как и в случае Борланда только через API.
Однако всё это касается только моей собственной персоны. Здесь я сам себе хозяин. Вопрос же топика был в другом. Стоит или нет навязывать другим то, что используешь сам? Да ещё в виде обязательных требований ТЗ.
при такой постановке вопроса - да, имеет смысл навязывать свой API 09.09.03 02:57  
Автор: йцукенг <jcukeng> Статус: Member
<"чистая" ссылка>
> 1) Вы так и не ответили на мой вопрос. Разумно, или не
> разумно набраться нам наглости, и «забить» в ТЗ
> ОБЯЗАТЕЛЬНОЕ ТРЕБОВАНИЕ для подрядчиков-программистов
> использовать только НАШЕ API, а не то, к чему он уже
> привык.
> Вопрос не праздный. Это некая наглость, диктат по отношению
> к программерам, поскольку во многом связывает им руки.
> Стоит или нет навязывать другим то, что используешь сам? Да
> ещё в виде обязательных требований ТЗ.

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

теперь что касается технологий MS. они потихоньку изменяют курс, сейчас вовсю продвигают .NET. кстати, на RSDN был обзор по производительности кода разных компиляторов, так вот, C# на одном из первых мест, VB - на последнем. это так, к слову пришлось...

*****
Я>>
причем велосипед ака сервер приложений можно не избобретать, а, например, взять в качестве >>него EAS от Sybase.
Приложения будут общаться с ним через CORBA (или как-то еще), на нем будут крутиться java >>beans, которые через JDBC будут работать с базами данных.
Вы>>
Здесь я Вас не понял. Про велосипед это понятно. Согласен. Но ведь современные средства программирования позволяют, как справедливо отметил один из авторов COM, «штамповать COM/DCOM сервера, как макароны». Для этого не надо даже понимать, что происходит «внутри», да и вообще быть сколь нибудь заметным программистом. Так, что мелкософт постарался здесь, как никогда хорошо. Поэтому мне легче дружить с мелкософтом при разработке мидлварных решений чем с «EAS от Sybase».
<<<
Я всего лишь имел в виду, что есть готовые сервера приложений, которые, возможно, будет правильнее использовать нежели писать свой с нуля - на это уйдет уйма времени и требует прежде всего очень грамотного проектирования.
[C++] Наверное, я плохо задал вопрос. 08.09.03 04:47  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
> 1) Вы так и не ответили на мой вопрос. Разумно, или не
> разумно набраться нам наглости, и «забить» в ТЗ
> ОБЯЗАТЕЛЬНОЕ ТРЕБОВАНИЕ для подрядчиков-программистов
> использовать только НАШЕ API, а не то, к чему он уже
> привык.
> Вопрос не праздный. Это некая наглость, диктат по отношению
> к программерам, поскольку во многом связывает им руки.

Это вполне обычная практика, особенно если речь идет о договоре на реализацию компонента системы и стоит вопрос стыковки с другими компонентами. Если абстрагироваться от баз данных, описание точек стыковки всегда лежит на авторе проекта системы в целом, и чем меньше роль подрядчиков в общесистемном проектировании, тем меньше у них прав голоса. Естественно, стоит сделать скидку на небольшой этап освоения предлагаемого API и обосновать необходимость его использования (с чем в данном случае проблем нет).
[C++] Да, спасибо Дмитрий (Отредактировано 1 раз). 08.09.03 06:12  
Автор: void <Grebnev Valery> Статус: Elderman
Отредактировано 08.09.03 06:55  Количество правок: 1
<"чистая" ссылка>
Чётко и ясно.
Спасибо за ответ.

Забыл сказать, поэтому редактирую свой пост.
Мы вообще намерены не только передать программерам API с документацией и примерами использования С/C++/VB но и:

1) передать исходный ASCII C++ код для того, чтобы программеры могли при желании посмотреть как это делается и при необходимости изменить нашу реализацию (разумеется если у них будут аргументы, что их реализация лучше)
2) предоставить механизм (в ASCII C++ коде) масштабирования API за счёт введения новых интерфейсов

Я очень надеюсь что в этом случае, когда мы передаём всё, что возможно программеры-подрядчики с меньшей неохотой бросят любимые DBGrid-ы и прочее баловство.
[c++] под ascii c++ имелся в виду, вероятно, ansi c++ ;) 08.09.03 14:14  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка>
> 1) передать исходный ASCII C++ код для того, чтобы
> программеры могли при желании посмотреть как это делается и
> при необходимости изменить нашу реализацию (разумеется если
> у них будут аргументы, что их реализация лучше)
> 2) предоставить механизм (в ASCII C++ коде) масштабирования
> API за счёт введения новых интерфейсов
>
> Я очень надеюсь что в этом случае, когда мы передаём всё,
> что возможно программеры-подрядчики с меньшей неохотой
> бросят любимые DBGrid-ы и прочее баловство.
К сожалению, не факт. Не каждый программист любит разбираться в незнакомом коде, особенно если этот код (с его точки зрения) плохо написан. А "плохо" очень часто означает "не так, как я пишу".
С другой стороны, некоторая затравка всегда полезна, особенно когда люди соображают в проектировании.
[C++] НЕТ 09.09.03 01:03  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Ktirf!
Говорю же, малограмотный я;)
Но здесь я имел ввиду именно ASCII, поскольку я хотел сказать, что мы будем передовать подрядчикам "исходники", т.е. текстовые С++ файлы.
Наверное, я, как всегда, не сумел простое понятие просто назвать.
Учту на будущее.
[C++] А-а :) Ну так файлы C++ другими и не бывают :) Теперь ясно :) 09.09.03 04:07  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка>
Согласен с мнением. 07.09.03 17:46  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка>
> причем велосипед ака сервер приложений можно не
> избобретать, а, например, взять в качестве него EAS от
> Sybase.
Это уже зависит от конкретной области. Иногда лучше свой AS написать.

> PS. совет - выбирайте такие СУБД, которые поддерживают
> хранимые пр-ры, при грамотном использовании сэкономите
> массу времени.
> а MS Access выкиньте ан помойку как можно раньше:)
По обоим пунктам - респект!!!
[C++] Согласен с мнением. 08.09.03 04:27  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Ktirf - Лёшка!
Спасибо за мнение. Вы как всегда правы, и Ваши рекомендации безусловно - хорошие, но Вы не ответили на мой вопрос.
Я спрашивал, стоит или нет в ТЗ закладывать специальные требования к сторонним разработчикам по методам доступа к данным.

>> По обоим пунктам - респект!!!
Я не владею компьютерным слэнгом. Если не затруднит- что есть "респект!!!"? Это ругательство в мою сторону?
[C++] Согласен с мнением. 08.09.03 14:10  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка>
Ну все, пора менять ник, слишком многие догадались :)

> Спасибо за мнение. Вы как всегда правы, и Ваши рекомендации
> безусловно - хорошие, но Вы не ответили на мой вопрос.
> Я спрашивал, стоит или нет в ТЗ закладывать специальные
> требования к сторонним разработчикам по методам доступа к
> данным.
Лучше всего заложить требование по обеспечению единообразного доступа на уровне Application Server (минус - автоматически навязывает использование трехзвенной архитектуры, ну да что уж делать). Каким будет этот единообразный доступ - решать вам.

> >> По обоим пунктам - респект!!!
> Я не владею компьютерным слэнгом. Если не затруднит- что
> есть "респект!!!"? Это ругательство в мою сторону?
Это калька с английского "respect", которая означает абсолютное согласие со словами собеседника и (вследствие этого) уважительное отношение к нему как к знающему человеку.
[C++] Респект ;) 09.09.03 01:46  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Да, спасибо за мнение. Для меня это важно.
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach