我们有一个相对较大的应用程序，它与Firebird（存储过程，视图等）紧密相关。我们现在收到很多支持其他数据库的请求，我们也希望将大量功能从客户端移到服务器上。
现在似乎是转向3（4）层架构的好时机。我们已经看过DataSnap 2009和RemObjects SDK / DataAbstract。他们似乎都会做这项工作，但是我们应该注意哪些优点/缺点？是否还有其他可以推荐的框架？
干杯， 保罗
答案 0 :(得分：4)
我可以推荐使用Components4Developers中的KBM Middleware组件。有一点学习曲线，但它们非常灵活，在现实世界条件下保持良好状态。
Comment from a user ( http://www.components4programmers.com/usercomments/commentfromapowerusertoaquestion.htm）
答案 1 :(得分：4)
使用新框架（RM，DS，kbmMW或以往任何时候）将应用程序更改为Multi-Tier，将在我们的应用程序架构中进行大量更改，我建议将来再使用它，但是您可以实现支持多数据库，其他产品如
来自DevArt的UniDac（具有直接连接的数据库的最佳组件）。 AnyDac（来自提供RemObjects的同一家公司）。 SqlDirect（支持9个MajorDB和ODBC）。 ZeosDB（开源）。
使用上面的其中一个组件，将为您提供大多数主要数据库的支持，除了它不会让您进行大量更改，在某些情况下，您只需用新的数据库组件替换旧的数据库组件，并可能更改一些属性。
但是，更改为多层不仅会使您只支持更多数据库，而且会将您的业务逻辑与表示层分开，因此您可以为应用程序（如Web界面或智能设备）提供更多表示层。 / p>
但是在Multi-Tiers架构中最重要的是，您将拥有一个可扩展的系统，其增长速度超过了您使用的数据库可以处理的连接，除了其他好处之外，例如使用其他语言编写客户端应用程序。
答案 2 :(得分：3)
在迁移到多层应用程序的过程中，您可以考虑在层之间使用传输协议，这与语言/技术无关（如webservices，（我认为remobjects支持））。
这可以让以后更简单地重新实现一个层（比如你以后必须在浏览器/ java / silverlight中创建另一个版本的客户端应用程序）。
答案 3 :(得分：1)
您还可以调查Midware http://www.overbyte.be/frame_index.html
答案 4 :(得分：1)
对于多层架构，我还建议您查看面向消息的中间件。
使用面向消息的中间件，可以使用对等或发布/订阅通信模型实现跨语言和跨平台应用程序集成。消息系统松散耦合，异步且可靠。例如，它们是Java（tm）应用程序服务器（如JBoss）中的核心组件。
对于Firebird，我最近撰写了一篇关于替换Firebird数据库事件的博客文章，它们的局限性以及用基于消息代理的解决方案（可作为开源提供）替换它们的方法：
（免责声明：我是开源消息代理的Delphi和Free Pascal客户端库的开发人员。）