Java中复杂的数据驱动的Web应用程序 - 技术决策

Dear Stack Overflow Community,

亲爱的Stack Overflow社区,

I am a Java programmer in front of a task of building a complex, data-driven, web application (SaaS) and I'm searching for technologies to use. I have already made some decisions and I believe I'm proficient enough to build the appliaction using just the technologies I have decided for (I'm definitely not saying it would be perfect, just that it would be working). However, I'd like to make my task easier and that's why I need your help.

我是一名Java程序员,负责构建复杂的,数据驱动的Web应用程序(SaaS),我正在寻找可以使用的技术。我已经做出了一些决定,我相信我已经足够熟练地使用我已经决定的技术来构建应用程序(我绝对不会说它会是完美的,只是它会起作用)。但是,我想让我的工作更轻松,这就是我需要你帮助的原因。

Brief description of the project

项目简要说明

Back-end

The application will be heavily data-driven, meaning that everything will be stored in a self-descripting database. This means the database itself will be entirely described with metadata and the application will not know what data it reads and writes. There won't probably be any regular entities (in terms of JPA @Entity) because the application won't know the structure of the data; it will obtain it from the metadata. Only the metadata will have a pre-determined structure. To put it simply, the metadata is the alpha-omega of the application because it will tell the application WHEN and WHAT to display and HOW to display it.

该应用程序将大量数据驱动,这意味着所有内容都将存储在自我描述的数据库中。这意味着数据库本身将完全用元数据描述,应用程序将不知道它读取和写入的数据。可能不会有任何常规实体(就JPA @Entity而言),因为应用程序不会知道数据的结构;它将从元数据中获取它。只有元数据才具有预定的结构。简单地说,元数据是应用程序的alpha-omega,因为它会告诉应用程序WHEN和WHAT显示以及如何显示它。

The application will probably utilize stored procedures to perform some low-level tasks on the data, such as automatical auditing, logging and translating to user's language, thus most likely eliminating any possibility to use ORM frameworks because there won't be just simple CRUD operations. Therefore, JDBC seems like my only option (doesn't it?).

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

Front-end

The UI will be "dumb" in terms that it will not know what data it is displaying (to some extent, of course). It will just know how to display it based on the metadata which it will obtain from the database. All UI controls (like menu items, buttons, etc) will be created based on current application's state and the UI will NOT know what the controls do. This means that clicking a menu item or a button will just send an identifier of associated action to the back-end and the server will decide what to do.

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

My goals

My main goal is to have the application as lightweight as possible with as least dependencies as possible. Because the application will be very complex, I'd like to avoid any heavy framework(s) because there is a very high probability that I'd need to customize a lot of its functionality.

我的主要目标是让应用程序尽可能轻量级,并尽可能减少依赖关系。因为应用程序将非常复杂,我想避免任何繁重的框架,因为我很有可能需要自定义其许多功能。

What I have already decided for

我已经决定了什么

Please object to the following decisions only if you think they're absolutely non-viable for my application, as I have already implemented some core functionality using these technologies:

只有当您认为它们对我的应用程序完全不可行时,请反对以下决定,因为我已经使用这些技术实现了一些核心功能:

• Servlets on Tomcat, Guice DI, AOP (AspectJ)
  I believe all of these technologies are lightweight enough and I don't need to learn J2EE.

  Tomcat,Guice DI,AOP(AspectJ)上的Servlet我相信所有这些技术都足够轻巧,我不需要学习J2EE。

• GWT with GIN-jection on the front-end
  Seems like the best option for me because I'm very familiar with Java and Swing and don't want to write any Javascript, PHP or learn a new language. GIN is a little brother of Guice and I will be using the same syntax and principles on both the client and server.

  GWT与前端的GIN-jection对我来说似乎是最好的选择,因为我对Java和Swing非常熟悉并且不想编写任何Javascript,PHP或学习新语言。 GIN是Guice的小兄弟,我将在客户端和服务器上使用相同的语法和原则。

• MSSQL RDBMS
  This is actually a requirement from company management as I'd much rather like to go with an open-source solution. Too bad for me..

  MSSQL RDBMS这实际上是公司管理层的要求,因为我更喜欢使用开源解决方案。对我来说太糟糕了..

• Maven 2
  I think no-one can object to this :)

  Maven 2我认为没有人可以反对这个:)

What I need help with

我需要帮助的是什么

• DB communication
  I think that ORM is ruled out (is it?) so I need to use JDBC. Do you think Spring JDBC is lightweight and flexible enough for my use? I would often need to "blindly" read data from database, mapping it to some generic entity (because I won't assume any pre-determined structure), and then send the data using some generic DTO to the client along with the metadata telling it what data it is and how to display it. Or do you know any alternatives? Or should I do this myself?

  数据库通信我认为ORM被排除了(是吗?)所以我需要使用JDBC。你认为Spring JDBC是否具有足够的轻量级和灵活性供我使用?我经常需要“盲目地”从数据库中读取数据,将其映射到某个通用实体(因为我不会假设任何预先确定的结构),然后使用一些通用DTO将数据与元数据一起发送给客户端它是什么数据以及如何显示它。或者您知道其他选择吗?或者我应该自己这样做?

• Client/Server communication
  GWT and its GWT-RPC mechanism seems not very suited for sending the generic data I need. Although I'm convinced that it's doable using GWT-RPC, are there any alternatives? But I definitely want to use GWT.

  客户端/服务器通信GWT及其GWT-RPC机制似乎不太适合发送我需要的通用数据。虽然我确信使用GWT-RPC是可行的,但还有其他选择吗?但我绝对想要使用GWT。

• Security
  Do you know any security libraries / frameworks that would help me? I'm aware of the existence of Spring-security; do you think it's flexible enough for my use or I'd be better off implementing that myself? Also, is Spring's IoC an integral part of the Spring framework, or would I be able to continue to use Guice?

  安全性您是否知道任何可以帮助我的安全库/框架?我知道Spring-security的存在;你觉得它的灵活性足以让我使用,或者我自己更好地实现它?另外,Spring的IoC是Spring框架不可或缺的一部分,还是我能继续使用Guice?

• Anything else that you think might be useful?

  你认为还有什么其他的东西可能有用吗?

I really appreciate any advice and suggestions because I wouldn't dare to try to make such decisions myself. Please ask me if you need more information.

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

Thank you in advance! eQui

先感谢您!球菌

4 个解决方案

#1

UI framework and implications for client/server communication

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

You say that any UI action will triger the backend (and potentially the DB). This mean that UI interraction will be somewhat slow anyway, and more than that will require a round trip to the server.

你说任何UI动作都会使后端(可能是数据库)变得棘手。这意味着无论如何UI交互都会有点慢,而且需要往返服务器。

GWT is especially suited to avoid as much as possible round trips to the server and do all UI work on client side. In this model, only information that will transit from client to server is real data, and not UI metadata. GWT will do the job, but you'll be using a somewhat low level tool, needed for advenced optimisation you'll be unable to perform anyway...

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

Framework like ZK or Vaadin seems more suited to what you want to do. The client side has nice widgets with a rich UI, but you manipulate the UI from the server side. The framework manage client/server communication for you (no need of REST, RPC or javascript). The main limitation of theses framework is scalability, with all theses chatty round trip. But because your requirement impose that chatty behaviour anyway, you could really benefit from the abstraction they provide, are they are at not cost in your case.

像ZK或Vaadin这样的框架似乎更适合您想要做的事情。客户端具有带有丰富UI的漂亮小部件,但您可以从服务器端操作UI。框架为您管理客户端/服务器通信(不需要REST,RPC或javascript)。这些框架的主要限制是可扩展性,所有这些都是常见的。但是因为你的要求无论如何强加了这种讨厌的行为,你真的可以从它们提供的抽象中受益,在你的情况下它们是不会花费的。

I have tried both GWT and Zk to do some proof of concept for my company. We ended choosing GWT, because of it's hability to be embedded nicelly into any existing UI and to fine tune what you do... In particular avoid as much as possible rountrip to server. But ZK is really easier and faster in term of developmeent hours.

我试过GWT和Zk为我的公司做一些概念验证。我们选择了GWT,因为它很难被嵌入任何现有的用户界面并微调你的工作......特别是尽可能避免rountrip到服务器。但是ZK在开发时间方面确实更容易,更快捷。

The side effect is that would totally solve your client/server communication concern, leting the framework performing it in an optimized way (Zk is able to intelligently regroup several UI event before sending them to server).

副作用是完全解决您的客户端/服务器通信问题,使框架以优化的方式执行它(Zk能够在将多个UI事件发送到服务器之前智能地重新组合它们)。

DB and ORM

DB和ORM

For DB design, i tend to think that using fine granularity things in DB will make it very very slow. If each widget is one or several rows in the database you'll have to perform many lookup to perform the simpliest thing.

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

Problem is if your UI is just a little complex with a few dozen of elements (a few button, checkboxes, labels and widgets), compositing a screen will require lot of requests to the DB. Rendering just one page might be very slow and scalability would be very very bad.

问题是如果你的UI只是有点几十个元素(一些按钮,复选框,标签和小部件)的复杂,合成一个屏幕将需要很多对数据库的请求。仅渲染一个页面可能非常慢,可伸缩性非常糟糕。

I know this because i worked on somewhat generic bug tracking system with similar (but simpler) requirements than yours and we had exactly this problem.

我知道这是因为我在一些通用的错误跟踪系统上工作,与你的相似(但更简单)的要求,我们确实遇到了这个问题。

So i would try to describe UI in some templating or XML format. Maybe you'll not show this data to the user, providing it with a nice abstraction, but instead of performning many queries for just one screen, you'll save the whole screen as one blob.

所以我会尝试用一些模板或XML格式来描述UI。也许你不会向用户显示这些数据,为它提供一个很好的抽象,但不是只为一个屏幕执行很多查询,你将整个屏幕保存为一个blob。

A really dumb and basic implementation of this would be to store HTML/CSS/PNG file in your DB and load it as needed, with user being responsible for making theses HTML file by hand. Of course this would be terrible for the user. That's why you need a nice and fancy editor UI editor that would work on an intermediary format of your own. Another dumb implementation would be some sort of wiki templating. This is not what you need, you need more. But you have the idea, I would seek in that direction...

一个非常愚蠢和基本的实现是在您的数据库中存储HTML / CSS / PNG文件并根据需要加载它,用户负责手动制作这些HTML文件。当然这对用户来说太糟糕了。这就是为什么你需要一个漂亮而精致的编辑器UI编辑器,它可以处理你自己的中间格式。另一个愚蠢的实现将是某种维基模板。这不是你需要的,你需要更多。但你有这个想法,我会朝这个方向寻求......

For the maintenance and debugging too, this would be far easier to the whole UI description to a few file, to understand what is really implemented than to read lot of tabuled data in your prefered SQL editor. Users would have they export/import format to easily version, backup or experiment.

对于维护和调试来说,对于一些文件来说,整个UI描述要容易得多,要理解什么是真正实现的,而不是在首选的SQL编辑器中读取大量的标签数据。用户可以使用导出/导入格式轻松进行版本,备份或实验。

Security

I would say by hand... Because you have a generic UI generated by user it seem likely that the security will be generic too and dependant of database content.

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

Hope it help...

希望它有所帮助......

#2

I think you are over-engineering the solution. Take a look at

我认为你过度设计了解决方案。看一眼

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

If everything is driven by the DB, you are going to have immense difficulty making things happen in the UI, and you aren't going to be able to use many of the tools that make UI development easier.

如果一切都是由数据库驱动的,那么在UI中发生事情将会非常困难,而且您将无法使用许多使UI开发更容易的工具。

I also suggest you take a look at Spring Roo, if your application is mainly just updating data in a database.

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

#3

For the backend, i implemented a program which had a similar interaction with the database. the code was database structure oblivious, instead, it read a config file describing the db and could construct complex sql queries based on this information. most of the code is proprietary, but one bit of it got pushed into an open source project called sqlbuilder. may be useful to you on the backend.

对于后端,我实现了一个与数据库具有类似交互的程序。代码是数据库结构不经意,相反,它读取描述数据库的配置文件,并可以根据此信息构造复杂的SQL查询。大部分代码都是专有的,但有一部分被推入了一个名为sqlbuilder的开源项目中。在后端可能对你有用。

#4

I think you're on the right track, with your tool seclection. Your 100% data driven model is going to be hard to maintain. But I understand that's a requirement not an option. Normal source control is going to fail you becuase of the ui application logic all being in the meta-data. You'll need some good test databases and some way to maintain them, such as regularily mysqldump them out and check them in to souce code control to handle all the differences, etc..

我认为你的工具正处于正确的轨道上。您的100%数据驱动模型将难以维护。但我明白这不是一个选择。正常的源代码控制将失败,因为ui应用程序逻辑都在元数据中。你需要一些好的测试数据库和一些维护它们的方法,例如定期mysqldump它们并检查它们到源代码控制来处理所有的差异等。

You're wise to stay away from various ORM solutions and just use JDBC for this type of app.

你最好远离各种ORM解决方案,只需将JDBC用于这种类型的应用程序。

Let me give you some warnings about GWT. On the surface it will abstract all the uglyness of html, javascript away and give you clean heirarchy's BUT...

让我给你一些关于GWT的警告。从表面上看,它将抽象出html,javascript的所有丑陋,并给你干净的heirarchy但是...

1) If the abstraction fails you how do you easily debug?

1)如果抽象失败,你如何轻松调试?

2) Do you want any of your site to be visible to Google or other search engines, if yes GWT is not for you

2)您是否希望Google或其他搜索引擎可以看到您的任何网站,如果是,GWT不适合您

3) Do you want to use any HTML5 technogies or do you want to be stuck in IE 5 compatability mode?

3)你想使用任何HTML5技术,还是想要陷入IE 5兼容模式?

So... I think you'll be much better off Implementing the UI as simple HTML controls with a small set of jQuery ajax interactions with the server. You can define an input type in your database, your serverlet can generate an input tag and then you have two options you can have some standard event bindings in jquery to tell your server that button1. is clicked, or that select2 has changed, etc. Your server can send back javascript to change the state of the ui - simply load the javascript inside a div so it runs on the client. or 2) You let the input submit the data to the server and do an old school page refesh and the servlet build the next ui screen based on the database.

所以......我认为通过与服务器进行一小组jQuery ajax交互来实现UI作为简单的HTML控件会更好。您可以在数据库中定义输入类型,您的serverlet可以生成输入标记,然后您有两个选项可以在jquery中使用一些标准事件绑定来告诉服务器button1。单击,或者select2已更改,等等。您的服务器可以发回javascript来更改ui的状态 - 只需在div中加载javascript,使其在客户端上运行。或者2)您让输入将数据提交给服务器并执行旧的学校页面refesh,并且servlet基于数据库构建下一个UI屏幕。

Building an interface dynamically in HTML from a database is easy and straight foward compared to doing the same in SWING or Windows Forms. You just have to write out a big text string, been doing that since 1999.

与在SWING或Windows窗体中执行相同操作相比,从数据库动态地在HTML中构建界面非常容易且直接。你必须写出一个大文本字符串,自1999年以来一直这样做。

That approach is going to be much more lightweight - simpler to debug, understand and modify in the long run than going with the "GWT automatically compiles to unreadable javascript that doesn't run in my browser for some unknown reason" solution.

这种方法将变得更加轻量级 - 从长远来看,调试,理解和修改比“GWT自动编译为无法在我的浏览器中运行的无法读取的javascript”解决方案更简单。