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

Question

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

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

Ура, Пол

Answer 1

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

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

Answer 5

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