У нас есть относительно большое приложение, которое сильно привязано к Firebird (хранимые процедуры, представления и т.д.). В настоящее время мы получаем много запросов на поддержку дополнительных баз данных, и мы также хотели бы переместить множество функций от клиента к серверу.
Теперь, похоже, хорошее время для перехода на 3 (4) уровень архитектуры. Мы уже рассмотрели DataSnap 2009 и RemObjects SDK/DataAbstract. Оба выглядят так, как будто они выполняют эту работу, но есть ли какие-либо преимущества/недостатки, которые мы должны искать? Есть ли другие рамки, которые вы могли бы порекомендовать?
Cheers, Пол
В процессе перехода к многоуровневому приложению вы можете использовать транспортный протокол между уровнями, который является независимым от языка/технологии (например, webservices, (я думаю, что remobjects поддерживает это)).
Это может сделать повторную реализацию слоя более простым позже (например, если позже вам придется сделать другую версию клиентского приложения в браузере/java/silverlight).
Я могу порекомендовать использовать компоненты промежуточного ПО KBM из компонентов4Developers. Существует немного кривой обучения, но они очень гибкие и хорошо поддаются использованию в реальных условиях.
Комментарий пользователя (http://www.components4programmers.com/usercomments/commentfromapowerusertoaquestion.htm)
Изменение вашего приложения в Multi-Tiers с помощью новой структуры (RM, DS, kbmMW или что-либо еще) приведет к большим изменениям в нашей архитектуре приложений, и я рекомендовал это сделать в будущем, но вы можете достичь поддержка нескольких баз данных, с другими продуктами, такими как
UniDac от DevArt (Лучшие компоненты для базы данных с прямым подключением). AnyDac (от той же компании, которая предлагает RemObjects. SqlDirect (имеет поддержку для 9 MajorDB, а также ODBC). ZeosDB (с открытым исходным кодом).
используя один из компонентов выше, предоставит вам поддержку для большинства основных баз данных, кроме того, это не заставит вас делать много изменений, а в некоторых случаях вы просто заменяете старые компоненты базы данных новыми и, возможно, меняете некоторые свойств.
Однако переход на многоуровневые уровни не только позволит вам поддерживать только больше баз данных, но и отделяет вашу бизнес-логику от уровня представления, поэтому вы можете иметь больше уровней представления для вашего приложения, например, веб-интерфейс или интеллектуальные устройства.
Но самое важное в архитектуре Multi-Tiers у вас будет масштабируемая система, которая будет расти больше, чем используемая вами база данных может обрабатывать соединение, помимо других преимуществ, например, использование других языков для написания клиентских приложений.
Вы также можете исследовать Midware http://www.overbyte.be/frame_index.html
Для многоуровневой архитектуры я также рекомендую проверить ориентированное на сообщения промежуточное программное обеспечение.
С ориентированным на сообщения промежуточным программным обеспечением кросс-язычная и кросс-платформенная интеграция приложений могут быть реализованы с использованием одноранговой или коммуникационной модели публикации/подписки. Системы обмена сообщениями слабо связаны, асинхронны и надежны. Например, они являются основными компонентами в серверах приложений Java (tm), таких как JBoss.
Для Firebird я недавно написал статью в блоге о замене событий базы данных Firebird, их ограничениях и способах замены их решениями, основанными на сообщениях-брокерах (которые доступны как с открытым исходным кодом):
(отказ от ответственности: я являюсь разработчиком клиентских библиотек Delphi и Free Pascal для брокеров сообщений с открытым исходным кодом).