Java中復雜的數據驅動的Web應用程序 - 技術決策

Question

親愛的Stack Overflow社區，

我是一名Java程序員，負責構建復雜的，數據驅動的Web應用程序（SaaS），我正在尋找可以使用的技術。 我已經做出了一些決定，我相信我已經足夠精通使用我已經決定的技術來構建應用程序（我絕對不會說它會是完美的，只是它會起作用）。 但是，我想讓我的工作變得更輕松，這就是我需要你幫助的原因。

項目簡要說明

后端

該應用程序將大量數據驅動 ，這意味着所有內容都將存儲在自我描述的數據庫中。 這意味着數據庫本身將完全用元數據描述，應用程序將不知道它讀取和寫入的數據。 可能不會有任何常規實體（就JPA @Entity而言），因為應用程序不會知道數據的結構; 它將從元數據中獲取它。 只有元數據才具有預定的結構。 簡單地說，元數據是應用程序的alpha-omega，因為它將告訴應用程序WHEN和WHAT顯示以及如何顯示它。

應用程序可能會利用存儲過程對數據執行一些低級任務，例如自動審計，記錄和轉換為用戶語言，因此很可能消除使用ORM框架的任何可能性，因為不會有簡單的CRUD操作。 因此，JDBC似乎是我唯一的選擇（不是嗎？）。

前端

UI將是“愚蠢的”，因為它不知道它顯示什么數據（當然，在某種程度上）。 它將只知道如何根據它將從數據庫中獲取的元數據來顯示它。 將根據當前應用程序的狀態創建所有UI控件（如菜單項，按鈕等），UI將不知道控件的作用。 這意味着單擊菜單項或按鈕只會將關聯操作的標識符發送到后端，服務器將決定要執行的操作。

我的目標

我的主要目標是讓應用程序盡可能輕量級，並盡可能減少依賴關系。 因為應用程序將非常復雜，我想避免任何繁重的框架，因為我很有可能需要自定義其許多功能。

我已經決定了什么

只有當您認為它們對我的應用程序完全不可行時，請反對以下決定，因為我已經使用這些技術實現了一些核心功能：

• Tomcat， Guice DI ，AOP（ AspectJ ）上的Servlet
  我相信所有這些技術都足夠輕巧，我不需要學習J2EE。

• GWT在前端使用GIN -jection
  對我來說似乎是最好的選擇，因為我對Java和Swing非常熟悉，並且不想編寫任何Javascript，PHP或學習新語言。 GIN是Guice的小兄弟，我將在客戶端和服務器上使用相同的語法和原則。

• MSSQL RDBMS
  這實際上是公司管理層的要求，因為我更願意使用開源解決方案。 對我來說太糟糕了..

• Maven 2
  我想沒有人可以反對這個:)

我需要幫助的是什么

• 數據庫通信
  我認為ORM被排除了（是嗎？）所以我需要使用JDBC。 你認為Spring JDBC是輕量級的還是足夠靈活的嗎？ 我經常需要“盲目地”從數據庫中讀取數據，將其映射到某個通用實體（因為我不會假設任何預先確定的結構），然后使用一些通用DTO將數據與元數據一起發送給客戶端它是什么數據以及如何顯示它。 或者您知道其他選擇嗎？ 或者我應該自己這樣做？

• 客戶/服務器通信
  GWT及其GWT-RPC機制似乎不太適合發送我需要的通用數據。 雖然我確信使用GWT-RPC是可行的，但還有其他選擇嗎？ 但我絕對想要使用GWT。

• 安全
  你知道任何可以幫助我的安全庫/框架嗎？ 我知道Spring-security的存在; 你認為它對我的使用是否足夠靈活，或者我自己更好地實現它？ 另外，Spring的IoC是Spring框架中不可或缺的一部分，還是我能夠繼續使用Guice？

• 你認為還有什么其他的東西可能有用嗎？

我非常感謝任何建議和建議，因為我不敢嘗試自己做出這樣的決定。 如果您需要更多信息，請詢問我。

先感謝您！ 球菌

Answer 1

我認為你過度設計了解決方案。 看一眼

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

如果一切都是由數據庫驅動的，那么在UI中發生事情將會非常困難，而且您將無法使用許多使UI開發更容易的工具。

如果您的應用程序主要只是更新數據庫中的數據，我還建議您查看Spring Roo。

Answer 2

對於后端，我實現了一個與數據庫具有類似交互的程序。 代碼是數據庫結構不經意，相反，它讀取描述數據庫的配置文件，並可以根據此信息構造復雜的SQL查詢。 大部分代碼都是專有的，但有一部分被推入了一個名為sqlbuilder的開源項目中。 在后端可能對你有用。

Answer 3

我認為你的工具正處於正確的軌道上。 您的100％數據驅動模型將難以維護。 但我明白這不是一個選擇。 由於ui應用程序邏輯都在元數據中，因此正常的源代碼控制將失敗。 你需要一些好的測試數據庫和一些維護它們的方法，例如定期mysqldump它們並檢查它們到源代碼控制來處理所有的差異等。

你最好遠離各種ORM解決方案，只需將JDBC用於這種類型的應用程序。

讓我給你一些關於GWT的警告。 從表面上看，它會抽象出html的所有丑陋，javascript離開並給你干凈的heirarchy 但是 ...

1）如果抽象失敗，你如何輕松調試？

2）您是否希望Google或其他搜索引擎可以看到您的任何網站，如果是，GWT不適合您

3）你想使用任何HTML5技術，還是想要陷入IE 5兼容模式？

所以...我認為通過與服務器進行一小組jQuery ajax交互來實現UI作為簡單的HTML控件會更好。 您可以在數據庫中定義輸入類型，您的serverlet可以生成輸入標記，然后您有兩個選項可以在jquery中使用一些標准事件綁定來告訴服務器button1。 單擊，或者select2已更改，等等。您的服務器可以發回javascript來更改ui的狀態 - 只需在div中加載javascript，使其在客戶端上運行。 或者2）您讓輸入將數據提交給服務器並執行舊的學校頁面refesh，並且servlet基於數據庫構建下一個UI屏幕。

與在SWING或Windows窗體中執行相同操作相比，從數據庫動態地在HTML中構建界面是簡單而直接的。 你必須寫出一個大文本字符串，自1999年以來一直這樣做。

這種方法將更加輕量級 - 從長遠來看，調試，理解和修改比“GWT自動編譯為無法在我的瀏覽器中運行的無法讀取的javascript”解決方案更簡單。

Answer 4

UI框架及其對客戶端/服務器通信的影響

你說任何UI動作都會使后端（可能是數據庫）變得棘手。 這意味着無論如何UI交互都會有點慢，而且需要往返服務器。

GWT特別適合盡可能避免往返服務器並在客戶端執行所有UI工作。 在此模型中，只有從客戶端傳輸到服務器的信息才是真實數據，而不是UI元數據。 GWT將完成這項工作，但你將使用一個稍微低級的工具，無論如何都要進行優化所需的優化......

像ZK或Vaadin這樣的框架似乎更適合您想要做的事情。 客戶端具有帶有豐富UI的漂亮小部件，但您可以從服務器端操作UI。 框架為您管理客戶端/服務器通信（不需要REST，RPC或javascript）。 這些框架的主要限制是可擴展性，所有這些都是常見的。 但是因為你的要求無論如何強加了這種討厭的行為，你真的可以從它們提供的抽象中受益，它們在你的情況下是不會花錢的。

我試過GWT和Zk為我的公司做一些概念驗證。 我們選擇了GWT，因為它很難被嵌入任何現有的用戶界面並對你所做的事情進行微調......特別是盡量避免使用rountrip到服務器。 但是ZK在開發時間方面確實更容易，更快捷。

副作用是完全解決您的客戶端/服務器通信問題，使框架以優化的方式執行它（Zk能夠在將多個UI事件發送到服務器之前智能地重新組合幾個UI事件）。

DB和ORM

對於數據庫設計，我傾向於認為在數據庫中使用細粒度的東西會使它非常慢。 如果每個小部件是數據庫中的一行或多行，則必須執行許多查找才能執行最簡單的操作。

問題是如果你的UI只是有點幾十個元素（一些按鈕，復選框，標簽和小部件）的復雜，合成一個屏幕將需要很多對數據庫的請求。 僅渲染一個頁面可能非常慢，可伸縮性非常糟糕。

我知道這是因為我在一些通用的bug跟蹤系統上工作的類似（但更簡單）的要求比你的要多，我們確實遇到了這個問題。

所以我會嘗試用一些模板或XML格式來描述UI。 也許你不會向用戶顯示這些數據，為它提供一個很好的抽象，但是你不會只為一個屏幕執行很多查詢，而是將整個屏幕保存為一個blob。

一個非常愚蠢和基本的實現是在您的數據庫中存儲HTML / CSS / PNG文件並根據需要加載它，用戶負責手動制作這些HTML文件。 當然這對用戶來說太糟糕了。 這就是為什么你需要一個漂亮而精致的編輯器UI編輯器，它可以處理你自己的中間格式。 另一個愚蠢的實現將是某種維基模板。 這不是你需要的，你需要更多。 但你有這個想法，我會朝那個方向尋求......

對於維護和調試來說，這對於一些文件的整個UI描述來說要容易得多，要理解什么是真正實現的，而不是在首選的SQL編輯器中讀取大量的標簽數據。 用戶可以使用導出/導入格式輕松進行版本，備份或實驗。

安全

我會手動說...因為你有一個由用戶生成的通用UI，所以安全性似乎也是通用的，並且依賴於數據庫內容。

希望它有所幫助......