Каморка

Админы рубанули серпом по любимой теме (предыдущий топик).
Ладно. Понятно. Но я хотел бы напоследок сделать пост для Yocto. Человек мне подсказал кое-что и это приятно. Если админы сочтут мой пост чрезмерной наглостью – ладно, соглашаюсь, но всё же попросил бы дать продолжению топика повисеть хоть пару дней. Потом можете убить. Мне хотелось бы уточнить для себя некоторые детали.
Я правда написал это пост ещё вчера. Но пропостить смог толькоо сегодня.

2 Yocto.

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

Согласен. Верное замечание.

Но вот определение границ уровней абстракции - момент достаточно тонкий. Например, класс, представляющий собой только лишь 'обёртку' и не имеющий дополнительной функциональности есть лишняя ненужная сущность….

Правильно говорите. Вопрос об «обёртках» здесь в некоторой степени преувеличен. Преследовалась две цели. При беглом чтении моих нудных постов должно было, как мне казалось, сложиться впечатление, что «обёртки» инкапсулируют вызовы профессиональной проги, и только (если читать внимательно мои посты – стошнит любого). Этого не случилось, т.к. некоторым товарищам на форуме продолжает казаться, что мы (или подрядчики) будут писать низкоуровневое API, а затем использовать фантики к ним.

Другая, более веская причина «навязывания» подрядчикам достаточно бедного по функционалу «обёрточного» API со строго оговоренным интерфейсом заключается в особенностях обработки данных в проектируемой ИС.

ИС состоит из 10-12 относительно «независимых» баз данных. Там подрядчики, используемые ими средства программирования, этапы разработки клиентского ПО будут разными. Общим является крайне оптимистический сценарий обработки данных. В таких условиях достаточно минимального интерфеса объектов доступа к данным при программировании клиентский приложений. Ввод/вывод - только буферизированный (на уровне клиентского ПО - обязательно). По другому там не сделаешь в предложенной спецификации. Никаких TDbGrid, TDbEdit-ов и других глупостей для малышей, как от борланда, так и от MS. Всё делаем только «руками». Никаких длительных или постоянных соединений с DBMS (разумеется, кэширование, пулинг самими DBMS или их API здесь не обсуждается – это их личное дело). Ни каких «автоматических» Query с непредсказуемыми результатами изменения данных. Если не построить для этого «заборы» в техзадании в виде необходимости следовать требованиям интерфейсов, то подрядчики могут «напрограммировать». Там тогда будет и гриды и актив-иксы. Чего только не будет. И не обязательно профессионального.

В моём представлении, управление isolation level со стороны клиента, если оно офрмлено как экспортируемые свойства (методы или переменные) - спорно.

Да спасибо, это Вы верно подметили, если мы говорим о том самом «гига-API». Пофиксим. Это просто по моей ошибке перекочевало из других классов, из библиотек, которые сам написал для себя, сам и использую (ну, я тоже иногда пишу программы, побазёнки, чтобы хоть немного подработать. Платят в России не очень). Конечно, программисты-подрядчики, пишущие клиентское ПО и близко не будут этим управлять. Управление уровнями изоляции транзакций будет в конфигах сервера приложений. Да…. Вы молодец. Внимательный.

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

Да, Вы безусловно правы. Что касается, меня, то я вообще еретик, иногда «злобно попирающий устои ООП». Главное результат, а не ложное чувство «необходимости соответствия» парадигмам того, аль иного.

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

Согласен. Я выразился опрометчиво, неверно. Иногда стереотипы давлеют, пока кто-нибудь другой не обратит на это внимание. Спасибо за комментарий по-существу.

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

Ооооо, такого постулатишка я и не выдвигал. Позднее связывание DLL – это просто то, что известно каждому. К middlware-вообще имеет по большому счёту весьма отдалённое отношение, если имеет вообще. Две трамвайных остановки. Идея была несколько в другом. Вас возможно несколько удивит, но когда эта проблематика обсуждалась с Российскими программистами (не такими, как я, а настоящими), то они тоже предлагали строить архитектуру, как чисто «трёхзвенную». Кто-то предлагалал, как Вы. Правда, в основном предлагалось строить всё на корбе, а не дэкоме, или ещё как. Т.е. ничего лишнего. Клиент -> корба сервер приложений -> то, что нужно серверу от RDBMS-ов (и не только RDBMS, как Вы совершенно справедливо замечаете в самом конце своего поста. странно, что другие местные даже не заметили этого у городских раньше).
Конечно, использование такого «чистого» подхода, наверное, очень хорошо для контор в России, которые ближе к Москве, Питеру (где можно без труда найти профи). А для Канады возможно следует идти вообще другим путём – как постил 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)             		' закрываем активный набор данных

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

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. Так яж об этом и писал в первом посте.

vg:
выглядит это так:

Клиентское ПО (запрос к серверу приложений) -> Сервер приложений (запрос к RDBMS) -> RDBMS.
Т.е. при использовании такой архитектуры клиентов разных типов может быть и сто, а сервер приложений и его API – один.

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

Согласен. Но так, и не так. Я не очень хотел здесь, в форуме распространяться о другой идеи, которая обсуждалась с Российскими программерами в части нашей ИС. Сервер приложений действительно нужен, см.п.3. (и в этой части кое-что «модельно» сделано).

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, и просто плоский файл.

Дык согласен, если использовать определения точнее, чем было сказано мною.

В очередной раз спасибо за мнение.

vg писал(а): Главное результат, а не ложное чувство «необходимости соответствия» парадигмам того, аль иного.

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

Подробности реализации обсуждаемого проекта мне неизвестны, поэтому я от советов воздержусь. За исключением одного, на мой взгляд, универсального:
Сомнения при принятии важных решений нужны, конечно, но только до определённого предела. Умей защищать свою точку зрения. По возможности предметно, не пользуясь новоязом либо жаргоном. Ясность изложения всегда говорит о ясности мышления. Тут у тебя, насколько я вижу, особых проблем нет. За свои ошибки отвечай и делай из них выводы. Ошибки у тебя будут, как и у всех. Твоё лично отношение к твоим профессиональным промахам - это твой профессиональный багаж, который некоторые называют опытом.

Одно замечание. Вот такое вот не совсем корректно

Код: Выделить всё

        If (hr <> S_OK) Then

Ошибками являются лишь отрицательные значения HRESULT. Положительные величины могут представлять status code, так что вышеприведённый код выглядит подозрительно.

Да, vg,

Yocto писал(а):Одно замечание. Вот такое вот не совсем корректно
Код: Выделить всё
        If (hr <> S_OK) Then
Ошибками являются лишь отрицательные значения HRESULT. Положительные величины могут представлять status code, так что вышеприведённый код выглядит подозрительно.

Код: Выделить всё

       if (FAILED(hr)) 
       {
                 // несработало по причине фатальной ошибки, невосстановимо
       }

hr == S_FALSE попадается, несработало по какой-то нефатальной причине, как-то занятость ресурса

"Can't open query" - тоже не очень, уж лучше "Query failed" или "Can't open dataset".

2 Yocto и Woozy,

Одно замечание. Вот такое вот не совсем корректно

Код:

If (hr <> S_OK) Then

Ошибками являются лишь отрицательные значения HRESULT. Положительные величины могут представлять status code, так что вышеприведённый код выглядит подозрительно.

Оооо!!!! Да, Вы правы

Ещё раз с удивлением вижу, на сколько Вы внимательны. Поразительно - прям Кашпировские (это в хорошем смысле).
Прикол в том, что раньше этой детали по неизвестной мне причине ещё никто не заметил!!!

(разумеется кроме меня самого, поскольку я сам писал тот бейсик-код и API) "Смягчающее" обстоятельство только в том, что делалось всё очень быстро ("модель"), возвращаемые значения - кодируются известными 32-разрядными значениями (как в COM). В конце упёрся в то, что не смог найти в бейсике нормальный "втроенный способ" проверки этих констант. На определённом этапе пришлось вообще бейсик-ориентированное API нескольно подрихтовать (в отличии от one для программеров Делфи, или С++). Так что здесь (для VB), если честно, не всё хорошо, как хотелось бы. Ну, да я надеюсь, профи пофиксят не только это, когда дело дойдёт до реализации опытного образца.

2 Woozy,

Код:

if (FAILED(hr))
{
// несработало по причине фатальной ошибки, невосстановимо
}

hr == S_FALSE попадается, несработало по какой-то нефатальной причине, как-то занятость ресурса

Разумеется. Так и делается. Но в С++. Там (см. выше) бейсик

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

#define FAILED(Status) ((HRESULT)(Status)<0)

Не стал пока. Я вообще не думал, что это дело "просекут". Пофиксят профи, когда дело дойдёт до проетирования. Вначале будет объявлен, думаю, тендер на разработку проекта. Деньги там не слабые. Следующая стадия - проект. А затем уж и реализации. Такая сложная схема разработки связана с некоторыми особенностями действующего законодательства и других нормативных актов в России, оговариващими как работы дозволено выполнять для Государевых контор.

"Can't open query" - тоже не очень, уж лучше "Query failed" или "Can't open dataset".

Согласен. Английский я знаю ещё хуже, чем программирование

.

Спасибо за мнение.

2Папа Карло.
Ну вот. Я всё узнал, что хотел. Теперь можешь закрыть топик.
А лучше всего удали его вообще.

зачем. пусть будет. а то придет vg2 и по второму кругу.

vg писал(а):Возможно я плохо искал, но в бейсике не смог найти процедуры-аналога макро FAILED.

Плохо искал. Найти невозможно.

А потому не нашёл, что VB вообще не рассматривает HRESULT COM метода, как возвращаемое значение, а генерит ошибку, когда HRESULT < 0. См On Error. Как возвращаемое значение VB рассматривает то что в COM методе [retval], если такой параметр объявлен у метода.

2Woozy,

Плохо искал. Найти невозможно.

Да, ладно... Это я так, со страху.

Честно говорю. Здесь и так некоторые местные-продвинутые (отодвинутые) от баз данных загоняли нас городских. Смешали с ...

А потому не нашёл, что VB вообще не рассматривает HRESULT COM метода, как возвращаемое значение, а генерит ошибку, когда HRESULT < 0. См On Error. Как возвращаемое значение VB рассматривает то что в COM методе [retval], если такой параметр объявлен у метода.

Мне вообще всегда нравился бейсик. Настоящий язык программирования. Для людей. Но, то что там такая хм, гм-гм...
обработка ошибок и исключительных ситуаций - плохо.
Я это не для того, чтобы поругать бейсик, как ты понимаешь. Думаю, не ругать, а хвалить нужно тех, кто его придумал (современная реализация). Я просто балдею, как там многие вещи получаются классно.
Для нас бейсик вообще очень важен. Это связано с тем, что большую часть клиентской проги, думаю, будут писать именно на бейсике. По опыту аналогичных ведомственных систем - точно. В этом нет ничего плохого и унизительного. Как ты понимаешь, писать на том-на сём нужно, пока пишется, и пишется хорошо.

А вообще с обработкой исключительных ситуаций, возникающих в коде API, вообще существует определённая проблема, на мой взгляд. И надо заранее оговаривать, как должно в этой части разрабатываться API, и каких правил должны придерживаться прикладные программеры. По крайней мере я с этим столкнулся. Признаюсь честно, глубоко обработку экзепшн внутри API не копал. Но, то, что это следует делать не так, как обычно - точно.

vg писал(а):Мне вообще всегда нравился бейсик. Настоящий язык программирования. Для людей.

А мы значит звери, да? то есть я конечно да

, но остальные то?

vg писал(а): Это связано с тем, что большую часть клиентской проги, думаю, будут писать именно на бейсике. ....В этом нет ничего плохого и унизительного.

Интересно, что в контексте разговора о любом другом языке, эта мысль выглядела бы странно, но в данном случае она вполне уместна...

2Marmot,

vg:
Мне вообще всегда нравился бейсик. Настоящий язык программирования. Для людей.
А мы значит звери, да? то есть я конечно да , но остальные то?

1) Мармот, я уже один раз высказался в части моей оценки Вашей квалификации. Вы как девица, хотите комплимент ещё. Перепалка, юмор или даже что другое (что Вам от непогоды показалось, но чего не было, на мой взгляд) - не меняют моего отношения к людям, в том числе и к Вам. В чём проблема-то?

2) Говорил я в том смысле про "Людей", что на бейсике могут и программируют многие специалисты в предметных областях (геология, строительство, и т.д.). Это очень хорошо, что люди без программистов могут решать большУю часть своих задач. И плохо, когда на производстве без программистов - кирдык.
Вы же, как и другие на этом форуме - программисты-профи. Или вы выполняете расчёты несущих строительных конструкций по предельным состояниям между делом?

Прим. Моё сдержанное, уважительное отношение к Вам != такое же отношение к некоторым персонажам. Поэтому с определением "остальные", я был бы осторожнее.

vg:
Это связано с тем, что большую часть клиентской проги, думаю, будут писать именно на бейсике. ....В этом нет ничего плохого и унизительного.
Интересно, что в контексте разговора о любом другом языке, эта мысль выглядела бы странно, но в данном случае она вполне уместна...

Да чего Вы на меня налетели? Лучше скажите своим хм, гм-гм, чтобы последние "воздерживались" от фраз "А Дельфи - засуньте себе...". Это было сказано как-то в мой адрес. Так вот считайте, что это для этих асемблеровщиков я пропостил. Заранее.

2vg
Ну прикалываюсь я, шутю
Захотелось вечером чего нибудь написАть, а тут message попался интересный, вот и написАл...
Кстати там же нету критики, просто наблюдения...

Уважение это конечно приятно, но мне этого мало

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

ЗЫ
Я тут всех пытаюсь немного интеллектуально изнасиловать...

Marmot писал(а):Я тут всех пытаюсь немного интеллектуально изнасиловать...

бык осеменитель мля

папа Карло писал(а):
Marmot писал(а):Я тут всех пытаюсь немного интеллектуально изнасиловать...
бык осеменитель мля

Ты же знаешь, философия у меня такая

Marmot писал(а):
папа Карло писал(а):
Marmot писал(а):Я тут всех пытаюсь немного интеллектуально изнасиловать...
бык осеменитель мля
Ты же знаешь, философия у меня такая

философия абсолютно правильная. нефиг на печи лежать. работать надо.

папа Карло писал(а):[ нефиг на печи лежать. работать надо.

У нас тут все дела начинаются в 8:30
Пойду keynotes слушать...

vg писал(а): Мне вообще всегда нравился бейсик. Настоящий язык программирования. Для людей. Но, то что там такая хм, гм-гм...

Но ты должен помнить что проф. софт. компании на нем не пишут.
Это только для профи в непрогр. областях.

--А вообще с обработкой исключительных ситуаций, возникающих в коде API, вообще существует определённая проблема, на мой взгляд.

Если бы только это - отсутствме полного ООП, unsigned types и многое другое

Каморка

Да простят меня модераторы

Да простят меня модераторы

Re: Да простят меня модераторы

Re: Да простят меня модераторы