Здесь я ещё меньший специалистvg, вы меня не совсем верно поняли (например я написал VC++, a не C++ )
А кто реально применял Managed C++?
Правила форума
Пожалуйста, ознакомьтесь с правилами данного форума
Пожалуйста, ознакомьтесь с правилами данного форума
-
- Маньяк
- Сообщения: 2803
- Зарегистрирован: 29 май 2003, 22:29
- Откуда: Магадан - Миссиссага
- Lepsik
- Житель
- Сообщения: 522
- Зарегистрирован: 17 фев 2003, 18:34
- Откуда: Berlin
- Контактная информация:
почитал я весь тред.
Что можно сказать. Папа Карло прав насчет ANSI SQL.
Я вот близок к выпуску первой версии нашего монстра.
И с ужасом понимаю что предстоит адаптировать под Oracle и DB2.
А это не в жабе протоколы заворачивать .
2 vg. Пиши все под ADO. Кухню кoторую вы заварить пытаетесь все равно долго без адаптации к новым технологиям не проживет, а если и слелаете свой API - производительность будет желать лучшего.
А потом или ишак сдохнет или султан
Что можно сказать. Папа Карло прав насчет ANSI SQL.
Я вот близок к выпуску первой версии нашего монстра.
И с ужасом понимаю что предстоит адаптировать под Oracle и DB2.
А это не в жабе протоколы заворачивать .
2 vg. Пиши все под ADO. Кухню кoторую вы заварить пытаетесь все равно долго без адаптации к новым технологиям не проживет, а если и слелаете свой API - производительность будет желать лучшего.
А потом или ишак сдохнет или султан
-
- Частый Гость
- Сообщения: 36
- Зарегистрирован: 07 окт 2003, 11:06
Что ж, подход известный. В каких-то ситуациях он вполне оправдан, в других может и нет. Мне трудно что-либо сказать, не зная самого проекта и его деталей. Попробую привести достаточно общие соображения.vg писал(а): Однако, я стараюсь
сделать такую работу один раз, например, "вылизав" соответствующие
алгоритмы и их реализацию, далее обернуть ЭТО в более высокоуровневые классы, и пользоваться в "текучке" только этими высокоуровневыми обёртками.
Стремление завернуть всё в классы и свести любой межмодульный обмен к вызовам интерфейсных методов возможно и неплохо.
In general. Особенно если знать меру.
Но вот определение границ уровней абстракции - момент достаточно тонкий. Например, класс, представляющий собой только лишь 'обёртку' и не имеющий дополнительной функциональности есть лишняя ненужная сущность. Его наличие можно оправдать только лишь улучшением читабельности кода, что, конечно, тоже очень важно для крупных проектов. Принцип бритвы говорит, что таких по возможности надо избегать.
В моём представлении, управление isolation level со стороны клиента, если оно офрмлено как экспортируемые свойства (методы или переменные) - спорно. Однако, не зная деталей, в критику вдаваться не буду. Это может быть оправдано в особых случаях.
Скажу только, что я по себе знаю, насколько тяжело не увлечься классовым подходом, применяя инкапсуляцию где надо и где не надо.
Это мне не очень понятно. API - это наиболее стабильный компонент в системе. А вот ODBC, в моём представлении, таковым не является. Видоизменяется он гораздо чаще и больнее. Хотя спорить не буду, использовать его или же нет и в какой мере во многих случаях определяется внешними требованиями, пожеланиями заказчика и т.п.vg писал(а): Постоянно и непосредственно обращаться к Win API, или к её части - на мой взгляд - дурной тон в программировании.
То есть является жёстко заданным критерием.
Дело в том, что указанные соглашения являются внутренним свойством определённого компилятора. Я бы не сказал, что динамическая подгрузка библиотек является лучшим способом для межмодульного общения. Если, к примеру, указанный кусок функциональности может быть выделен в отдельную сущность (ну, скажем, daemon/сервис со строго определённым интерфейсным набором), то было бы полезно не делать выводов по поводу того, на каком боксе это хозяйство работает.vg писал(а): Не удаётся сделать так, чтобы вызывающий софт мог использовать соглашения паскаль (как для ВинАпи).
Понятно, что взаимодействие по схеме 'GetProcAddress' не является масштабируемым, в отличие от стандартных сетевых транспортов.
Вот именно в такой интерпретации "Сервер приложений (запрос к RDBMS)" указанная архитектура является двухзвенной. Поскольку в этом случае сервер приложений и собственно DB являются одной логической сущностью. Просто с неким разделением функций.vg писал(а): выглядит это так:
Клиентское ПО (запрос к серверу приложений) -> Сервер приложений (запрос к RDBMS) -> RDBMS.
Т.е. при использовании такой архитектуры клиентов разных типов может быть и сто, а сервер приложений и его API – один.
Трёхзвенной она будет в том случае, когда сервер приложения полностью абстрагирует клиента от механизма сохранения данных. Это ведь может быть и Active Directory, и просто плоский файл.
-
- Маньяк
- Сообщения: 2771
- Зарегистрирован: 20 фев 2003, 09:15
- Откуда: Vancouver
Ну что я могу сказать по этому поводу?
Вот уж обосрали так обосрали. Как мона спорить с человеокм который даже не знает сто функция Cast - это Transiational ANsi SQL а к примеру Оракл поддерживает тольок начальный уровень?
А уж что касается знаю ли я как разарабатываются информационные системы- я то у ж знаю. Причем я знаю как это делают в Северной Америке и в СССР. СССР правда уже нету но явно в России их разрабатывают по советским методикам как видно. Одно совершенно верно - тут и там методики несколько разные.
А уж что касается знаю ли я как разарабатываются информационные системы- я то у ж знаю. Причем я знаю как это делают в Северной Америке и в СССР. СССР правда уже нету но явно в России их разрабатывают по советским методикам как видно. Одно совершенно верно - тут и там методики несколько разные.
-
- Маньяк
- Сообщения: 2803
- Зарегистрирован: 29 май 2003, 22:29
- Откуда: Магадан - Миссиссага
2Lepsik,
То, что предлагается (у меня это работает года три с небольшим) позволяет до определённой степени свободно претранслировать лексемы SQL к диалекту той DBMS, которая в данный момент "прописана" в конфигах.
2) "Свой API" о котором ты пишешь - у нас это "дейстующая модель", разработать которую, не составило труда. Читаешь - не внимательно. Я постил, что ядро сервера приложений (ПО промежуточного слоя) и его API будут писать профи, а не мы. Мы вообще не умеем программировать по большому счёту.
Так прав. Я ж об этом и постил. Или не вразумительно написал, или ты невразумительно прочитал.Что можно сказать. Папа Карло прав насчет ANSI SQL.
То, что предлагается (у меня это работает года три с небольшим) позволяет до определённой степени свободно претранслировать лексемы SQL к диалекту той DBMS, которая в данный момент "прописана" в конфигах.
1) Банально. То, что не существует универсальных технологий на все 100 - кто ж спорит? Мы только пытаемся минимизировать риски. T.е. обойтись без перекомпиляции клиентского ПО, насколько это окажется возможным. Понятно, что возможно полностью этого и не избежать. НО основная масса изменений вносилась бы в ПО промежуточного слоя, а не в клиентскую прогу.2 vg. Пиши все под ADO. Кухню кoторую вы заварить пытаетесь все равно долго без адаптации к новым технологиям не проживет, а если и слелаете свой API - производительность будет желать лучшего.
2) "Свой API" о котором ты пишешь - у нас это "дейстующая модель", разработать которую, не составило труда. Читаешь - не внимательно. Я постил, что ядро сервера приложений (ПО промежуточного слоя) и его API будут писать профи, а не мы. Мы вообще не умеем программировать по большому счёту.
- Lepsik
- Житель
- Сообщения: 522
- Зарегистрирован: 17 фев 2003, 18:34
- Откуда: Berlin
- Контактная информация:
- Marmot
- Графоман
- Сообщения: 38418
- Зарегистрирован: 17 фев 2003, 17:58
- Откуда: Canyon Heights
- Контактная информация:
Это была всего лишь слегка модифицированная цитата из "Бориса Годунова"Lepsik писал(а):2 папа Карла
--Короче, это мой последний пост в этом топике.
--У меня от него уже сплошные Lepsikи кровавые в глазах
"И все тошнит, и голова кружится, и мальчики кровавые в глазах... " (с) А.С. Пушкин
Плохо мне было...
Добавление:
Упс, извиняюсь, я же обещал больше сюда не писать...
- папа Карло
- Шарманщик
- Сообщения: 8563
- Зарегистрирован: 17 фев 2003, 15:04
- Откуда: НН -> BC -> WA -> UT -> CA