关于迁移到多层 Delphi 架构的建议答案

【问题标题】：Advice on moving to a multi tier Delphi architecture关于迁移到多层 Delphi 架构的建议
【发布时间】：2010-10-07 09:38:36
【问题描述】：

我们有一个相对较大的应用程序，它与 Firebird 紧密相关（存储过程、视图等）。我们现在收到了很多支持其他数据库的请求，我们还希望将很多功能从客户端转移到服务器。

现在似乎是迁移到 3(4) 层架构的好时机。我们已经看过 DataSnap 2009 和 RemObjects SDK/DataAbstract。两者似乎都可以胜任，但是我们应该注意哪些优点/缺点？您还有其他可以推荐的框架吗？

干杯，保罗

【问题讨论】：

Delphi 正在积极开发中。
约翰，你为什么不回答提出的问题，而是发表一些废话？ Delphi 的开发非常活跃，几个月前刚刚发布了一个新版本，并为未来的版本制定了路线图。为什么要发布不正确的 FUD？
约翰，我想你对 Delphi 了解不多 :-)
我们当前的应用程序是用 Delphi 编写的。对我们来说，转换为多层系统比将现有代码翻译成另一种语言要容易得多。此外，我们不想转向另一种语言。 Delphi 非常活跃，完全能够满足我们的需求。

【解决方案1】：

对于多层架构，我还建议查看面向消息的中间件。

借助面向消息的中间件，可以使用点对点或发布/订阅通信模型实现跨语言和跨平台的应用程序集成。消息系统是松耦合、异步和可靠的。例如，它们是 JBoss 等 Java(tm) 应用服务器中的核心组件。

对于 Firebird，我最近写了一篇关于替换 Firebird 数据库事件、它们的局限性以及用基于消息代理的解决方案（可作为开源）替换它们的方法的博客文章：

（免责声明：我是用于开源消息代理的 Delphi 和 Free Pascal 客户端库的开发人员）。

【讨论】：

【解决方案2】：

你也可以调查Midware http://www.overbyte.be/frame_index.html

【讨论】：

【解决方案3】：

使用新框架（RM、DS、kbmMW 或任何其他框架）将您的应用程序更改为多层，将对我们的应用程序架构进行大量更改，我建议将来使用此方法，但您可以实现支持多数据库，与其他产品类似

UniDac 来自 DevArt（直接连接数据库的最佳组件）。 AnyDac（来自提供 RemObjects 的同一家公司。 SqlDirect（支持 9 MajorDB 和 ODBC）。 ZeosDB（开源）。

使用上述组件之一，将为您提供对大多数主要数据库的支持，除此之外，它不会让您做很多更改，在某些情况下，您只需用新的数据库组件替换旧的数据库组件，并且可能会更改一些属性。

但是，更改为多层不仅会使您只支持更多的数据库，而且会将您的业务逻辑与表示层分开，因此您可以为您的应用程序（如 Web 界面或智能设备）提供更多的表示层。

但在多层架构中最重要的是，您将拥有一个可扩展的系统，该系统的增长速度超过了您使用的数据库可以处理的连接，此外还有其他好处，例如使用其他语言编写客户端应用程序。

【讨论】：

【解决方案4】：

我可以推荐使用 Components4Developers 的 KBM 中间件组件。有一点学习曲线，但它们非常灵活，并且在现实世界条件下使用得很好。

【讨论】：

【解决方案5】：

在迁移到多层应用程序的过程中，您可以考虑在各层之间使用传输协议，该协议独立于语言/技术（如 web 服务，（我认为 remobjects 支持））。

这可以在以后简化层的重新实现（例如，如果您以后必须在浏览器/java/silverlight 中创建另一个版本的客户端应用程序）。

【讨论】：