Java中的复杂数据驱动web应用技术决策

Question

亲爱的堆栈溢出社区，

我是一名Java程序员，在构建一个复杂的、数据驱动的web应用程序(SaaS)的任务面前，我正在寻找要使用的技术。我已经做了一些决定，我相信我已经足够熟练地使用我决定使用的技术来构建应用程序(我肯定不是说它会是完美的，只是它会起作用)。然而，我想使我的任务更容易，这就是为什么我需要你的帮助。

项目简介

后端

应用程序将是高度数据驱动的，这意味着所有的东西都将存储在一个自描述数据库中。这意味着数据库本身将完全由元数据描述，应用程序将不知道它读取和写入什么数据。可能不会有任何常规实体(就JPA @Entity而言)，因为应用程序不知道数据的结构；它将从元数据中获得数据。只有元数据才具有预先确定的结构。简单地说，元数据是应用程序的alpha-omega，因为它将告诉应用程序何时显示、显示什么以及如何显示。

应用程序可能会利用存储过程对数据执行一些低级任务，如自动审核、日志记录和转换为用户语言，因此很可能消除使用ORM框架的任何可能性，因为不只是简单的CRUD操作。因此，JDBC似乎是我唯一的选择(不是吗？)

前端

UI将是“哑”的，因为它将不知道它正在显示什么数据(当然，在某种程度上)。它只知道如何根据从数据库获得的元数据来显示它。所有UI控件(如菜单项、按钮等)都将根据当前应用程序的状态创建，UI将不知道控件的作用。这意味着单击菜单项或按钮只会向后端发送关联操作的标识符，服务器将决定要做什么。

我的目标

我的主要目标是使应用程序尽可能轻量级，尽可能少依赖项。由于应用程序将非常复杂，所以我想避免使用任何繁重的框架，因为我很可能需要定制它的许多功能。

我已经为做了什么决定

如果您认为以下决定对我的应用程序完全不可行，请反对以下决定，因为我已经使用这些技术实现了一些核心功能：

• Servlets on Tomcat，Guice DI，AOP (AspectJ) 我相信所有这些技术都足够轻量级，我不需要学习J2EE。
• GWT和前端的GIN-jection 对我来说，这似乎是最好的选择，因为我非常熟悉Java和Swing，不想编写任何Javascript、PHP或学习新语言。GIN是Guice的弟弟，我将在客户机和服务器上使用相同的语法和原则。
• MSSQL关系数据库管理系统 这实际上是公司管理层的一项要求，因为我更愿意使用开源解决方案。对我来说太糟了..。
• Maven 2 我认为没有人能反对这一点:)

我需要的帮助

• DB通信 我认为ORM被排除在外了(是吗？)所以我需要使用JDBC。您认为Spring的轻量级和灵活性是否足以供我使用？我通常需要“盲目地”从数据库读取数据，将其映射到某个泛型实体(因为我不会假定任何预先确定的结构)，然后使用一些通用DTO将数据发送给客户端，同时还需要元数据告诉它它是什么数据以及如何显示它。或者你知道其他的选择吗？还是我自己来做？
• 客户机/服务器通信 GWT及其generic机制似乎不太适合发送我需要的通用数据。虽然我确信使用GWT-RPC是可行的，但还有其他选择吗？但我绝对想使用GWT。
• 安全 您知道哪些安全库/框架可以帮助我吗？我知道Spring安全性的存在；您认为它对于我的使用是否足够灵活，或者我最好自己实现它？而且，Spring的IoC是Spring框架的一个组成部分，还是我能够继续使用Guice？
• 还有其他你认为有用的吗？

我真的很感激任何建议和建议，因为我不敢自己做这样的决定。如果你需要更多的信息，请问我。

提前谢谢你！eQui

Answer 1

UI框架及其对客户机/服务器通信的影响

您说任何UI操作都会破坏后端(以及潜在的DB)。这意味着UI交互无论如何都会比较慢，而且还需要往返到服务器。

GWT特别适合避免尽可能多地往返到服务器，并在客户端执行所有UI工作。在此模型中，只有从客户端传输到服务器的信息才是真实的数据，而不是UI元数据。GWT将完成这项工作，但您将使用一个级别较低的工具，这是高级优化所需要的，无论如何，您将无法执行.

像ZK或Vaadin这样的框架似乎更适合您想要做的事情。客户端有很好的具有丰富UI的小部件，但是您可以从服务器端操作UI。该框架为您管理客户机/服务器通信(不需要REST、RPC或javascript)。这些框架的主要限制是可伸缩性，所有这些聊天往返。但是，因为您的需求强加了这种闲聊行为，所以您可以从它们提供的抽象中真正受益，如果在您的情况下它们不需要付出代价的话。

我已经尝试过GWT和Zk为我的公司做一些概念的证明。我们结束了选择GWT，因为它可以很好地嵌入到任何现有的UI和微调您所做的.特别是尽量避免往返到服务器。但ZK在开发时间上确实更容易、更快。

副作用是完全解决了客户机/服务器通信问题，让框架以一种优化的方式执行它(Zk能够智能地重新组合几个UI事件，然后再发送到服务器)。

DB与ORM

对于DB设计，我倾向于认为在DB中使用细粒度会使它变得非常慢。如果每个小部件是数据库中的一个或几个行，则必须执行许多查找才能执行最简单的操作。

问题是，如果您的UI只是有点复杂，有几十个元素(几个按钮、复选框、标签和小部件)，那么组合一个屏幕将需要大量对DB的请求。只呈现一个页面可能会非常慢，而且可伸缩性也会非常糟糕。

我之所以知道这一点，是因为我使用了一些与您类似(但更简单)的bug跟踪系统，而且我们确实遇到了这个问题。

因此，我会尝试以某种模板或XML格式描述UI。也许您不会将这些数据显示给用户，为其提供一个很好的抽象，但与其对一个屏幕执行许多查询，不如将整个屏幕保存为一个blob。

这方面的一个非常愚蠢和基本的实现是将HTML/CSS/PNG文件存储在您的DB中，并根据需要加载它，用户负责手工制作这些HTML文件。当然，这对用户来说是很糟糕的。这就是为什么您需要一个优秀的编辑器UI编辑器，它可以使用您自己的中间格式。另一个愚蠢的实现是某种wiki模板。这不是你需要的，你需要更多。但你有个主意，我会朝那个方向去.

对于维护和调试，对于一些文件的整个UI描述来说，理解什么是真正实现的要比在您喜欢的SQL编辑器中读取大量表格数据要容易得多。用户需要导出/导入格式以方便版本、备份或实验。

安全

我会说用手..。因为您有一个由用户生成的通用UI，所以安全性似乎也是通用的，并且依赖于数据库内容。

希望它能帮上忙。

Answer 2

我觉得你想得太多了。看一看

http://thedailywtf.com/Articles/Programming-Sucks!-Or-At-Least,-It-Ought-To-.aspx

如果一切都是由DB驱动的，那么您将很难在UI中实现任何事情，并且您将无法使用许多使UI开发更容易的工具。

我还建议您看看Spring，如果您的应用程序主要是更新数据库中的数据。

Answer 3

对于后端，我实现了一个与数据库进行类似交互的程序。代码不是数据库结构，而是读取一个描述db的配置文件，并可以根据这些信息构造复杂的sql查询。大部分代码都是专有的，但是有一部分代码被推到了一个名为建筑工地的开源项目中。在后端可能对你有用。