Каморка

vg, вы меня не совсем верно поняли (например я написал VC++, a не C++ )

Здесь я ещё меньший специалист

почитал я весь тред.

Что можно сказать. Папа Карло прав насчет ANSI SQL.
Я вот близок к выпуску первой версии нашего монстра.
И с ужасом понимаю что предстоит адаптировать под Oracle и DB2.

А это не в жабе протоколы заворачивать .

2 vg. Пиши все под ADO. Кухню кoторую вы заварить пытаетесь все равно долго без адаптации к новым технологиям не проживет, а если и слелаете свой API - производительность будет желать лучшего.

А потом или ишак сдохнет или султан

vg писал(а): Однако, я стараюсь
сделать такую работу один раз, например, "вылизав" соответствующие
алгоритмы и их реализацию, далее обернуть ЭТО в более высокоуровневые классы, и пользоваться в "текучке" только этими высокоуровневыми обёртками.

Что ж, подход известный. В каких-то ситуациях он вполне оправдан, в других может и нет. Мне трудно что-либо сказать, не зная самого проекта и его деталей. Попробую привести достаточно общие соображения.
Стремление завернуть всё в классы и свести любой межмодульный обмен к вызовам интерфейсных методов возможно и неплохо.
In general. Особенно если знать меру.
Но вот определение границ уровней абстракции - момент достаточно тонкий. Например, класс, представляющий собой только лишь 'обёртку' и не имеющий дополнительной функциональности есть лишняя ненужная сущность. Его наличие можно оправдать только лишь улучшением читабельности кода, что, конечно, тоже очень важно для крупных проектов. Принцип бритвы говорит, что таких по возможности надо избегать.
В моём представлении, управление isolation level со стороны клиента, если оно офрмлено как экспортируемые свойства (методы или переменные) - спорно. Однако, не зная деталей, в критику вдаваться не буду. Это может быть оправдано в особых случаях.
Скажу только, что я по себе знаю, насколько тяжело не увлечься классовым подходом, применяя инкапсуляцию где надо и где не надо.

vg писал(а): Постоянно и непосредственно обращаться к Win API, или к её части - на мой взгляд - дурной тон в программировании.

Это мне не очень понятно. API - это наиболее стабильный компонент в системе. А вот ODBC, в моём представлении, таковым не является. Видоизменяется он гораздо чаще и больнее. Хотя спорить не буду, использовать его или же нет и в какой мере во многих случаях определяется внешними требованиями, пожеланиями заказчика и т.п.
То есть является жёстко заданным критерием.

vg писал(а): Не удаётся сделать так, чтобы вызывающий софт мог использовать соглашения паскаль (как для ВинАпи).

Дело в том, что указанные соглашения являются внутренним свойством определённого компилятора. Я бы не сказал, что динамическая подгрузка библиотек является лучшим способом для межмодульного общения. Если, к примеру, указанный кусок функциональности может быть выделен в отдельную сущность (ну, скажем, daemon/сервис со строго определённым интерфейсным набором), то было бы полезно не делать выводов по поводу того, на каком боксе это хозяйство работает.
Понятно, что взаимодействие по схеме 'GetProcAddress' не является масштабируемым, в отличие от стандартных сетевых транспортов.

vg писал(а): выглядит это так:

Клиентское ПО (запрос к серверу приложений) -> Сервер приложений (запрос к RDBMS) -> RDBMS.

Т.е. при использовании такой архитектуры клиентов разных типов может быть и сто, а сервер приложений и его API – один.

Вот именно в такой интерпретации "Сервер приложений (запрос к RDBMS)" указанная архитектура является двухзвенной. Поскольку в этом случае сервер приложений и собственно DB являются одной логической сущностью. Просто с неким разделением функций.
Трёхзвенной она будет в том случае, когда сервер приложения полностью абстрагирует клиента от механизма сохранения данных. Это ведь может быть и Active Directory, и просто плоский файл.

Вот уж обосрали так обосрали. Как мона спорить с человеокм который даже не знает сто функция Cast - это Transiational ANsi SQL а к примеру Оракл поддерживает тольок начальный уровень?

А уж что касается знаю ли я как разарабатываются информационные системы- я то у ж знаю. Причем я знаю как это делают в Северной Америке и в СССР. СССР правда уже нету но явно в России их разрабатывают по советским методикам как видно. Одно совершенно верно - тут и там методики несколько разные.

2Lepsik,

Что можно сказать. Папа Карло прав насчет ANSI SQL.

Так прав. Я ж об этом и постил. Или не вразумительно написал, или ты невразумительно прочитал.
То, что предлагается (у меня это работает года три с небольшим) позволяет до определённой степени свободно претранслировать лексемы SQL к диалекту той DBMS, которая в данный момент "прописана" в конфигах.

2 vg. Пиши все под ADO. Кухню кoторую вы заварить пытаетесь все равно долго без адаптации к новым технологиям не проживет, а если и слелаете свой API - производительность будет желать лучшего.

1) Банально. То, что не существует универсальных технологий на все 100 - кто ж спорит? Мы только пытаемся минимизировать риски. T.е. обойтись без перекомпиляции клиентского ПО, насколько это окажется возможным. Понятно, что возможно полностью этого и не избежать. НО основная масса изменений вносилась бы в ПО промежуточного слоя, а не в клиентскую прогу.

2) "Свой API" о котором ты пишешь - у нас это "дейстующая модель", разработать которую, не составило труда. Читаешь - не внимательно. Я постил, что ядро сервера приложений (ПО промежуточного слоя) и его API будут писать профи, а не мы. Мы вообще не умеем программировать по большому счёту.

2 папа Карла

--Короче, это мой последний пост в этом топике.
--У меня от него уже сплошные Lepsikи кровавые в глазах

А в форуме есть процедуры наказания страдающих недержанием.
Этот мальчик не то что в модераторы, на собеседника не тянет

Lepsik писал(а):2 папа Карла

--Короче, это мой последний пост в этом топике.
--У меня от него уже сплошные Lepsikи кровавые в глазах

Это была всего лишь слегка модифицированная цитата из "Бориса Годунова"
"И все тошнит, и голова кружится, и мальчики кровавые в глазах... " (с) А.С. Пушкин
Плохо мне было...

Добавление:
Упс, извиняюсь, я же обещал больше сюда не писать...

закрыл нафиг.