在多层上下文中摆动富客户端

Question

我们正处于未来Swing应用程序的分析/早期设计阶段，其中持久性由数据库提供（可能是Oracle和mySql之间的替代方案，具体取决于客户的资金）。

基本上，该应用程序将具有两种模块：

• 一个“admin”子系统，用于提供和维护一组参考数据;
• X其他子系统使用此数据的子集并构建自己的对象（在商业意义上），引用这些子集的元素。

我的问题是：

1. 我猜最好的做法是将可部署的Swing应用程序仅限于表示事务，并让它在远程服务器上查询业务层，这个“更深层”的应用程序是唯一可以访问数据库和负责持久性问题。是否有理由我们可以决定采用其他方式让Swing应用程序直接与数据库对话（无需单独的业务层）？在决策过程中，我可以提供哪些参数来支持半技术人员的业务层架构？
2. 您是否会为此类解决方案（n层上下文中的富客户端）提供设计考虑因素（框架，模式，代码约定）？
3. 在编码阶段是否有可以帮助我们的工具，尤其是将参考数据子集检索到Swing应用程序，缓存管理以及完整性验证（检查修改后的实体是Swing应用程序）发送回DB不会替换自提取以来提交的其他修改？

Answer 1

这听起来像是为Web服务实现而定制的应用程序。您的前端调用Web服务以获取数据或返回数据以保持持久性。业务层在服务器上运行，负责为客户端打包数据。

1. 对于非技术人员，我发现的最好方法是与外界专家打动。在网上找到有关面向服务的体系结构和Web服务的白皮书（此时可能大约有十年历史），向他们展示您所建议的是接受的体系结构。您将编写代码 - 功能必须以某种方式存在 - 确保以可维护的方式编写代码。

您还可以解释测试会更容易，编码会更容易，并且将来添加功能将更容易，更直接。

\ 2。 3. apache.org网站已经编写了许多功能，可以随时使用（当你快速了解如何使用它时。）查看Jakarta和Web Services项目组。

Answer 2

我绝不是这方面的专家，但我有一些可能有帮助的想法 1）将处理表示层的代码与处理业务逻辑的代码分开是一种标准做法。 Swing框架本身通过MVC模式强制执行此操作。话虽如此，你为什么要考虑与数据库交互的远程服务器？这当然是一种选择，但您必须考虑到各种网络延迟。您是否关心GUI的更新速度？您可以有一个演示文稿撕裂，即设计和构建项目，以便您有一个层（与表示层分开）与本地而不是远程服务器的DB交互。在关于非技术人员争论的问题中，我假设使用远程服务器。如果您认为它必须是远程的，您可以展示脱钩，性能和整体设计的好处 2）如果您想拥有远程业务层，则可以使用Web服务。虽然它必须是遥远的吗？

Answer 3

2层架构（您的Swing客户端直接连接到数据库）通常更简单，更容易实现并且更便宜，因为它涉及更少的代码，更少的系统和更少的技术（您不需要了解Web服务，Java EE等。）

如果出于以下原因之一，3层架构（Swing客户端，应用程序服务器，数据库服务器）可能会有所帮助：

1. 如果在应用程序服务器上实现安全性（身份验证，授权）比在数据库服务器上实现安全性更高。在双层体系结构中，您需要为每个最终用户设置数据库用户，并且需要正确保护所有表和过程。在3层体系结构中，通常可以使用单个技术用户连接到数据库。

2. 如果无法从客户端直接连接到数据库，因为安全策略禁止它或网络基础结构（防火墙）阻止它。

3. 如果难以在每个桌面上部署新版本的客户端软件。在3层体系结构中，只需在应用程序服务器上部署新版本即可修复50％ - 70％的错误。

如果您需要使用3层体系结构，您可能需要查看Java EE（Java Enterprise Edition）以及实现它的应用程序服务器（JBoss，GlassFish，WebLogic等）。有很多关于Java EE最佳实践的文献。但请注意，Java EE很复杂，学习曲线也很陡峭。

对于数据库访问，我会看一下Hibernate。除了非常适合数据库访问而不必处理niffty JDBC细节外，它还支持防止丢失更新的机制。