Database 关于迁移到多层Delphi体系结构的建议

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

现在似乎是转向3（4）层体系结构的好时机。我们已经了解了DataSnap 2009和ReObjects SDK/DataAbstract。两人似乎都能胜任这项工作，但我们有什么优点/缺点需要注意吗？您还可以推荐其他框架吗

干杯，

---

保罗

< P>在移动到多层应用程序的过程中，您可以考虑使用层间的传输协议，这是语言/技术无关的（如WebServices）（我想RoistBubor支持这一点）。

---

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

我建议使用Components4Developer中的KBM中间件组件。有一点学习曲线，但它们非常灵活，在现实世界条件下使用起来很好

---

)

使用新框架（RM、DS、kbmMW等）将您的应用程序更改为多层，这将对我们的应用程序体系结构带来很大的变化，我建议以后继续这样做，但您可以通过其他产品实现对多数据库的支持，如

来自DevArt（直接连接数据库的最佳组件）。 （来自提供改造对象的同一家公司。 （支持9 MajorDB和ODBC）。 （开源）

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

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

---

但在多层体系结构中最重要的是，除了使用其他好处（如使用其他语言编写客户端应用程序）外，您将拥有一个可扩展的系统，该系统的增长将超过您正在使用的数据库所能处理的连接ut面向消息的中间件

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

对于Firebird，我最近写了一篇关于替换Firebird数据库事件的博客文章，介绍了它们的局限性以及用基于message broker的解决方案（开源）替换它们的方法：

---

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

Delphi正在积极开发。John，你为什么不回答所问的问题，而是发表一些废话？Delphi非常积极开发，几个月前刚刚发布了一个新版本，并为未来的发布制定了路线图。为什么发布FUD这不是真的？John，我想你对Delphi了解不多：-）我们当前的应用程序是用Delphi编写的。对于我们来说，转换成多层系统比将现有代码转换成另一种语言要容易得多。此外，我们不想转移到另一种语言。Delphi非常活跃，完全能够满足我们的需求。这是一个关于KBM中间件的视频，视频中的声音和图片质量非常差。我喜欢他在讨论1层、2层和3层的优缺点时的方式。只有3层没有缺点：）