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