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

Question

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

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

Аплодисменты Павел

Answer 1

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

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

Answer 2

Я могу порекомендовать использовать компоненты KBM Middleware от Components4Developers.Требуется некоторое время обучения, но они очень гибкие и хорошо выдерживают использование в реальных условиях.

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

Answer 3

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

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

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

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

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

Answer 4

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

Answer 5

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

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

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

• События базы данных Firebird и промежуточное программное обеспечение, ориентированное на сообщения (часть 1)
• События базы данных Firebird и промежуточное ПО, ориентированное на сообщения (часть 2)

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