Рекомендации по переходу на многоуровневую архитектуру Delphi

У нас есть относительно большое приложение, которое сильно привязано к Firebird (хранимые процедуры, представления и т.д.). В настоящее время мы получаем много запросов на поддержку дополнительных баз данных, и мы также хотели бы переместить множество функций от клиента к серверу.

Теперь, похоже, хорошее время для перехода на 3 (4) уровень архитектуры. Мы уже рассмотрели DataSnap 2009 и RemObjects SDK/DataAbstract. Оба выглядят так, как будто они выполняют эту работу, но есть ли какие-либо преимущества/недостатки, которые мы должны искать? Есть ли другие рамки, которые вы могли бы порекомендовать?

Cheers, Пол

Ответ 1

В процессе перехода к многоуровневому приложению вы можете использовать транспортный протокол между уровнями, который является независимым от языка/технологии (например, webservices, (я думаю, что remobjects поддерживает это)).

Это может сделать повторную реализацию слоя более простым позже (например, если позже вам придется сделать другую версию клиентского приложения в браузере/java/silverlight).

Ответ 2

Я могу порекомендовать использовать компоненты промежуточного ПО KBM из компонентов4Developers. Существует немного кривой обучения, но они очень гибкие и хорошо поддаются использованию в реальных условиях.

Комментарий пользователя (http://www.components4programmers.com/usercomments/commentfromapowerusertoaquestion.htm)

Ответ 3

Изменение вашего приложения в Multi-Tiers с помощью новой структуры (RM, DS, kbmMW или что-либо еще) приведет к большим изменениям в нашей архитектуре приложений, и я рекомендовал это сделать в будущем, но вы можете достичь поддержка нескольких баз данных, с другими продуктами, такими как

UniDac от DevArt (Лучшие компоненты для базы данных с прямым подключением). AnyDac (от той же компании, которая предлагает RemObjects. SqlDirect (имеет поддержку для 9 MajorDB, а также ODBC). ZeosDB (с открытым исходным кодом).

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

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

Но самое важное в архитектуре Multi-Tiers у вас будет масштабируемая система, которая будет расти больше, чем используемая вами база данных может обрабатывать соединение, помимо других преимуществ, например, использование других языков для написания клиентских приложений.

Ответ 4

Вы также можете исследовать Midware http://www.overbyte.be/frame_index.html

Ответ 5

Для многоуровневой архитектуры я также рекомендую проверить ориентированное на сообщения промежуточное программное обеспечение.

С ориентированным на сообщения промежуточным программным обеспечением кросс-язычная и кросс-платформенная интеграция приложений могут быть реализованы с использованием одноранговой или коммуникационной модели публикации/подписки. Системы обмена сообщениями слабо связаны, асинхронны и надежны. Например, они являются основными компонентами в серверах приложений Java (tm), таких как JBoss.

Для Firebird я недавно написал статью в блоге о замене событий базы данных Firebird, их ограничениях и способах замены их решениями, основанными на сообщениях-брокерах (которые доступны как с открытым исходным кодом):

(отказ от ответственности: я являюсь разработчиком клиентских библиотек Delphi и Free Pascal для брокеров сообщений с открытым исходным кодом).