Ладно. Понятно. Но я хотел бы напоследок сделать пост для Yocto. Человек мне подсказал кое-что и это приятно. Если админы сочтут мой пост чрезмерной наглостью – ладно, соглашаюсь, но всё же попросил бы дать продолжению топика повисеть хоть пару дней. Потом можете убить. Мне хотелось бы уточнить для себя некоторые детали.
Я правда написал это пост ещё вчера. Но пропостить смог толькоо сегодня.
2 Yocto.
Согласен. Верное замечание.Что ж, подход известный. В каких-то ситуациях он вполне оправдан, в других может и нет. Мне трудно что-либо сказать, не зная самого проекта и его деталей. Попробую привести достаточно общие соображения.
Стремление завернуть всё в классы и свести любой межмодульный обмен к вызовам интерфейсных методов возможно и неплохо.
In general. Особенно если знать меру.
Правильно говорите. Вопрос об «обёртках» здесь в некоторой степени преувеличен. Преследовалась две цели. При беглом чтении моих нудных постов должно было, как мне казалось, сложиться впечатление, что «обёртки» инкапсулируют вызовы профессиональной проги, и только (если читать внимательно мои посты – стошнит любого). Этого не случилось, т.к. некоторым товарищам на форуме продолжает казаться, что мы (или подрядчики) будут писать низкоуровневое API, а затем использовать фантики к ним.Но вот определение границ уровней абстракции - момент достаточно тонкий. Например, класс, представляющий собой только лишь 'обёртку' и не имеющий дополнительной функциональности есть лишняя ненужная сущность….
Другая, более веская причина «навязывания» подрядчикам достаточно бедного по функционалу «обёрточного» API со строго оговоренным интерфейсом заключается в особенностях обработки данных в проектируемой ИС.
ИС состоит из 10-12 относительно «независимых» баз данных. Там подрядчики, используемые ими средства программирования, этапы разработки клиентского ПО будут разными. Общим является крайне оптимистический сценарий обработки данных. В таких условиях достаточно минимального интерфеса объектов доступа к данным при программировании клиентский приложений. Ввод/вывод - только буферизированный (на уровне клиентского ПО - обязательно). По другому там не сделаешь в предложенной спецификации. Никаких TDbGrid, TDbEdit-ов и других глупостей для малышей, как от борланда, так и от MS. Всё делаем только «руками». Никаких длительных или постоянных соединений с DBMS (разумеется, кэширование, пулинг самими DBMS или их API здесь не обсуждается – это их личное дело). Ни каких «автоматических» Query с непредсказуемыми результатами изменения данных. Если не построить для этого «заборы» в техзадании в виде необходимости следовать требованиям интерфейсов, то подрядчики могут «напрограммировать». Там тогда будет и гриды и актив-иксы. Чего только не будет. И не обязательно профессионального.
Да спасибо, это Вы верно подметили, если мы говорим о том самом «гига-API». Пофиксим. Это просто по моей ошибке перекочевало из других классов, из библиотек, которые сам написал для себя, сам и использую (ну, я тоже иногда пишу программы, побазёнки, чтобы хоть немного подработать. Платят в России не очень). Конечно, программисты-подрядчики, пишущие клиентское ПО и близко не будут этим управлять. Управление уровнями изоляции транзакций будет в конфигах сервера приложений. Да…. Вы молодец. Внимательный.В моём представлении, управление isolation level со стороны клиента, если оно офрмлено как экспортируемые свойства (методы или переменные) - спорно.
Да, Вы безусловно правы. Что касается, меня, то я вообще еретик, иногда «злобно попирающий устои ООП». Главное результат, а не ложное чувство «необходимости соответствия» парадигмам того, аль иного.Скажу только, что я по себе знаю, насколько тяжело не увлечься классовым подходом, применяя инкапсуляцию где надо и где не надо.
Согласен. Я выразился опрометчиво, неверно. Иногда стереотипы давлеют, пока кто-нибудь другой не обратит на это внимание. Спасибо за комментарий по-существу.Это мне не очень понятно. API - это наиболее стабильный компонент в системе. А вот ODBC, в моём представлении, таковым не является. Видоизменяется он гораздо чаще и больнее. Хотя спорить не буду, использовать его или же нет и в какой мере во многих случаях определяется внешними требованиями, пожеланиями заказчика и т.п.
То есть является жёстко заданным критерием.
Ооооо, такого постулатишка я и не выдвигал. Позднее связывание DLL – это просто то, что известно каждому. К middlware-вообще имеет по большому счёту весьма отдалённое отношение, если имеет вообще. Две трамвайных остановки. Идея была несколько в другом. Вас возможно несколько удивит, но когда эта проблематика обсуждалась с Российскими программистами (не такими, как я, а настоящими), то они тоже предлагали строить архитектуру, как чисто «трёхзвенную». Кто-то предлагалал, как Вы. Правда, в основном предлагалось строить всё на корбе, а не дэкоме, или ещё как. Т.е. ничего лишнего. Клиент -> корба сервер приложений -> то, что нужно серверу от RDBMS-ов (и не только RDBMS, как Вы совершенно справедливо замечаете в самом конце своего поста. странно, что другие местные даже не заметили этого у городских раньше).Дело в том, что указанные соглашения являются внутренним свойством определённого компилятора. Я бы не сказал, что динамическая подгрузка библиотек является лучшим способом для межмодульного общения. Если, к примеру, указанный кусок функциональности может быть выделен в отдельную сущность (ну, скажем, daemon/сервис со строго определённым интерфейсным набором), то было бы полезно не делать выводов по поводу того, на каком боксе это хозяйство работает.
Понятно, что взаимодействие по схеме 'GetProcAddress' не является масштабируемым, в отличие от стандартных сетевых транспортов.
Конечно, использование такого «чистого» подхода, наверное, очень хорошо для контор в России, которые ближе к Москве, Питеру (где можно без труда найти профи). А для Канады возможно следует идти вообще другим путём – как постил Marmot (см. выше про жаву) . Но для того района, где я живу – сомнительно. Это потребует от разработчиков очень и очень хорошего знания предмета. В этом случае всё должно проектироваться с самого начала на этой платформе - с использованием корбы и дэкома. Опасно это. Расхлёбывать будет некому здесь. Разве, что тупым оленям и медведям.
Поэтому, было принято промежуточное решение – когда в трехзвенную архитектуру добавляется ещё одно четвёртое звено. Это звено – дополнительное ПО, установленное на клиенте. Интерфейсы его Вы видели Выше. Смысл этого ПО заключается в том, за таким API может стоять всё, что угодно – непосредственное обращение к интерфейсам OLE DB, или далее к серверу приложений. Как это API напишешь, (вернее сказать перепишешь при модернизации), так и будет фактически работать. Клиенты этого даже не заметят. Говорю, не голословно. Для этого «модель» и писалась. Работает. Разумеется пока.
Выше я постил код бейсика. Очень надеюсь, что меня простят модераторы за перепост. Ещё раз (про «пятый» элемент в четырёхзвенной архитектуре):
(1)Клиент-> (2) lpc API -> (3)«маршалинг» к объектам сервера приложений ->(4)DBMS.
С точки зрения СТОРОННЕГО прикладного программиста (который за тысячи километров от нас будет реализовывать нашу ИС) – это и будет использование нашего 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) ' закрываем активный набор данных2) Вот дэком решение. У меня есть соображения, почему в нашей СЕТЕВОЙ ИНФРАСТРУКТУРЕ отъявленный мелкософт лучше. Там вызовы такие:
Код: Выделить всё
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 ' закрываем активные наборы данныхКлиент-«супертонкий». Реализация объектов доступа к данным лежит на мидлаврном сервере.
Сравните код в п.1 (lpc) и п.2.(middleware). С точки зрения прикладного программиста, по большому счёту - ВСЁ ОДИНАКОВО. И в одном, и в другом случае он использует методы чёрного ящика – API. Так яж об этом и писал в первом посте.
Согласен. Но так, и не так. Я не очень хотел здесь, в форуме распространяться о другой идеи, которая обсуждалась с Российскими программерами в части нашей ИС. Сервер приложений действительно нужен, см.п.3. (и в этой части кое-что «модельно» сделано).vg:
выглядит это так:
Клиентское ПО (запрос к серверу приложений) -> Сервер приложений (запрос к RDBMS) -> RDBMS.
Т.е. при использовании такой архитектуры клиентов разных типов может быть и сто, а сервер приложений и его API – один.
Вот именно в такой интерпретации "Сервер приложений (запрос к RDBMS)" указанная архитектура является двухзвенной. Поскольку в этом случае сервер приложений и собственно DB являются одной логической сущностью. Просто с неким разделением функций.
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 =…..
Дык согласен, если использовать определения точнее, чем было сказано мною.Трёхзвенной она будет в том случае, когда сервер приложения полностью абстрагирует клиента от механизма сохранения данных. Это ведь может быть и Active Directory, и просто плоский файл.
В очередной раз спасибо за мнение.
.
, но остальные то?
