Технологии создания frontend и backend частей программы.
Слышал, что скажем ядро может быть написано на сях, а интерфейс, к примеру на Visual Basic или на Дельфях... Но ка это реализовать на практике?
Можно конечно сделать сервер и к нему цеплять клиентскую интерфейсную часть, но не слишком ли все усложняется?
Не подскажите ли какие существуют стандарты и технологии программирования, обеспечивающие разделение оформления программы от его содержимого?
Прежде всего интересует программирование под win платформами. Но и возможность безболезненого портирования безусловно тоже важна.
Это наводит на мысль о том, что изначально структура проекта была продумана недостаточно хорошо. По идее, back-end должен быть чёрным ящиком с интерфейсом, к нему "подключаются" средства ввода/вывода. Это же справедливо и для front-end.
Технология DLL отработана достаточно хорошо. ;) А что мешает использовать Visual C++? Код на Си должен в этой среде компилироваться, насколько помню.
А так или иначе оно к тому и сводится. А вообще что мешает использовать DLL или что-нибудь подобное?
Классический ответ... :( Я спрашиваю какие варианты, какие способы реализации и что можно сделать - ответ плохо спроектировано. :)
Причем тут DLL? Куда я извиняюсь в Линуксе эту DLL вставлю? Речь идет не о созании API для разработки приложений, а о создании самодостаточного приложения, отдельного черного ящика, желательно платформопереносимого, к которому потом цепляется любая, хоть сторонне разработанная оболочка ввода вывода.
Вот одним из вариантов такой реализации я вижу клиент серверную реализацию.
Так же сейчас на вскидку погу припомнить ту же яву с ее виртуальной машиной... И спрашиваю, существуют ли вообще технологии стандартизирующие операции ввода вывода между frontend и backend, вроде виртуальной Java машины, дабы не изобретать велосипед...
RPC уже интересней, но так понимаю является клиент серверной реализацией, что в принципе неплохо, но так скажем не ново.
Немного сублимируя, хочется описать то что нужно более конкретно. Создается "черный ящик" с абстрактной логикой, написаный скажем на чистом C++ без платформеной специфики. Этот "черный ящик" имеет стандартизированый интерфейс ввода вывода, позволяющий ящику:
а) подключатся к системным ресурсам - com портам, жескому диску, и т.п.
б) Интегрироватся в пользовательский интерфейс специфичный для платформы.
Соответственно вопрос, существуют ли технологии позволяющие организовать подобный стандариизированный интерфейс черного ящика, и как дело обстоит с реализацией на разных платформах? На Java все это реализуется через надстройку виртуальной машины. А есть ли в C++ что то подобное, но как бы самодостаточное?
К примеру, проект состоял бы из 3х модулей:
GUI - обеспечение стандартизированого пользовательского ввода-вывода
Core - логика
System - реализация взаимодействия с системой.
Все три модуля обменивывались бы данными по определенному стандарту, что позволило бы разделить разработку и скоординировать ее. Ну и вести и расширять такую программу в будущем будет удобней...
Собственно не хотелось бы самостоятельно изобретать велосипед, а использовать какие либо существующие наработки...
Может быть, мой ответ и был похож на отмазку, но если
то это говорит только о плохом проектировании системы.;)
А в чём проблема? Под Линукс компилируется библиотека и вперёд.:)
Вот одним из вариантов такой реализации я вижу клиент серверную реализацию.
Вспоминается, как сделана SVN. Там, насколько помню, вообще всё это крутится на Апаче. Кроссплатформенность отменная. В самом деле, почему нельзя написать модуль к Апачу?
Предлагаю начать с уточнения того, что система делает и чем конкретно занимаются frontend и backend, какие к ним требования. Это очень интересно.
Вспоминается, как сделана SVN. Там, насколько помню, вообще всё это крутится на Апаче. Кроссплатформенность отменная. В самом деле, почему нельзя написать модуль к Апачу?
На апаче - это только один из вариантов исспользования, для тех кому непременно надо работать через HTTP. А вобще у SVN есть ссвой сервер и свой протокол никак не зависящий от апача, что позволяет ставить его как полноценный сервер.
Кто бы спорил? Просто когда говорят о кроссплатформенности, мне часто кажется, что говорят зря. Насколько и в каких рамках реально нужна кроссплатформенность? Почему-то обычно забывают про то, что людям не нужна платформа, им нужна программа. Под программу найдётся и платформа. Впрочем, если оставить софистику, то можно достаточно неплохо компилировать консольные программы на Си под разные платформы и это будет прекрасно работать. Как их снабдить интерфейсом пользователя - вопрос другой. Лично мне напрашивается веб-интерфейс, поскольку как кроссплатформенное решение это практически идеальный вариант.
Опять же, прежде чем что-то проектировать, очень полезно определиться с тем, что делают front-/backend части, какой интерфейс нужен и для чего. Хороши кроссплатформенный GUI делается в виде веб-интерфейса, хороший кроссплатформенный интерфейс взаимодействия между частями приложения - TCP/IP. Как кроссплатформенные решения эти варианты очень хороши. Если надо быстродействие - тогда под каждую конкретную платформу надо делать своё решение.
Ну можно еще QT, GTK и подобное для них исспользовать.
GUI - обеспечение стандартизированого пользовательского ввода-вывода
Core - логика
System - реализация взаимодействия с системой.
В принципе, .NET как-раз реализует подобную схему, только разрабатывать придется на C#, с оглядкой на Mono - он не так уж полно поддерживает Framework 2.0.
Mono скорее не поддерживает второй фреймворк, чем поддерживает. Впрочем, можно и для первого фреймворка написать, на Mono должно работать. Другой вопрос, что второй значительно богаче первого, стало быть, придётся писать много того, что уже было написано.
А можно взять веб-сервер и использовать веб-интерфейс. Как кроссплатформенное решение получится наверняка лучше, чем Qt и GTK.
чем лучше? )
Веб-интерфейс одинаково функционирует и одинаково выглядит почти на любой платформе. Под виндой он не требует установки библиотек GTK или Qt. Он вообще ничего не требует кроме браузера. Наконец, он изменяется централизованно. В остальном веб-интерфейс не лучше.
Он так же неодинаково может выглядеть в разных браузерах на разных платформах и требует сети. Плюс нормального браузера. Плюс все ограничения которые имеет веб интерфейс на клиентской машине. Опять же в дистрибутив с софтиной можно запихать все нужные либы. Я к тому что обобщать все это бессмысленно. Для каких то задачь где нужна сеть имеет смысл веб интерфейс, для каких то сеть и веб вобще не приемлимы, а нужно обычное десктоп приложение.
т. е. автора интересует, что будет в точке х
| ЛОГИКА |----х-----| ИНТЕРФЕЙС |
сейчас модно использовать XML, например. т. е. - черный ящик отдает ХМЛ блоки, а интерфейс выдает это в удобоваримом виде.
Ну дак а чеб не поддержать оффтоп. )
т. е. автора интересует, что будет в точке х
| ЛОГИКА |----х-----| ИНТЕРФЕЙС |
сейчас модно использовать XML, например. т. е. - черный ящик отдает ХМЛ блоки, а интерфейс выдает это в удобоваримом виде.
[QUOTE="Владимир Высоцкий"]Разошёлся, так и сыпет:
"Треугольник будет выпит,
Будь он параллелепипед,
Будь он круг, едрёна вошь!"[/QUOTE]
Ещё в точке Х может быть какой-нибудь байт-код, если нет возможности писать XML-парсер. Хотя XML, в принципе, удобная штука. SOAP, например... Просто может быть, что XML - не самое оптимальное решение. Опять же, без требований к системе трудно сказать, что надо использовать, а что не стоит.