动态产品的技术选择

Question

我们正在用JAVA为采购领域建立一个产品。

以下是主要的技术要求。

1. 平台无关
2. 数据库无关
3. 浏览器无关

在功能需求方面，产品的性质是非常动态的。主要原因是世界各地的采购过程因客户而异。

简单地说，我们需要一个动态工作流引擎和一个动态模板引擎。工作流引擎可以定义任意类型的工作流，模板引擎允许定义任意类型的数据结构，并在定义的基础上通过工作流获取用户的输入。

我们已经开发这个产品近两年了。过了很长一段时间，我们才能了解需求的动态。

到目前为止，我们已经开发了一个基本的工作流和模板引擎，并在其中一个客户端使用。

我们一直在使用以下技术。

1. GWT-Ext (前端框架)
2. 休眠(数据库层)

在此期间，由于hibernate中的子类划分，我们在GWT(主要是浏览器兼容性)和数据库优化方面遇到了一些问题。

为了解决GWT问题，这是一个垂死的社区，所以我们决定转移到SmartGWT。在SmartGWT中，我们遇到了与加载相关的问题，现在我们能够最终确定GWT2.3将是前进的道路，因为这个库非常丰富，性能也达到了标准。

我们几乎能够完成基于GWT-Spring的前端和中间层。

在hibernate中，我们发现了子类的主要问题，因为它会抛出天文数字的查询，有时它会在5-10秒内停止触发任何查询，或者可能是30秒左右，然后再继续。几天前，我来到了一个与ORM相关的文章。

我是一个传统的.Net SQL开发人员，我一直在处理关系数据库。阅读这篇文章，我也发现它与我所面临的问题有关。我仍然不完全相信使用hibernate，本文只是支持我的观点。

以下是我正在寻找答案的问题。

1. 在动态数据库需求的情况下，我们是否应该使用Hibernate，而且将来数据的负载将很重？我们如何划分数据，如何有效地加入数据，如何优化查询？如果答案是否定的，那么我们如何实现数据库独立呢？
2. 我们的选择是否与GWT和Spring相关，还是我们也需要改变这一点？
3. 如果数据本质上是动态的，并且很难使其成为关系数据库，那么我们是否应该使用其他键值对数据库呢？

Answer 1

浏览器独立相对容易实现，如果这是一个web应用程序，那么平台独立性就不是一个问题(除非您指的是部署平台)，java在很大程度上提供了这一点。

数据库独立是一个完全不同的问题。在20年的软件编写过程中，我一直未能正确破解那个软件。而且，TBH，一旦你有了一个成功的产品，而且客户愿意为此付出代价，那么它实际上并不重要。

在某种程度上，我支持tdammers的评论。从这方面来说，我实际上主张不要使用任何ORM工具。对于需要复杂和多样的数据持久性的任何东西，ORM工具都不会满足您的需要。使用自己正确实现的数据访问层，您的情况要好得多。这将使您可以灵活地在需要时重构和子类，并将数据库查询调优到正确的位置。