複雜數據驅動的Web應用程序 - 在技術決策

Question

親愛的堆棧溢出社區，

我在構建一個複雜的，數據驅動的web應用程序的任務的前一個Java程序員（SaaS）和我正在尋找使用的技術。我已經做出了一些決定，並且我相信我足夠熟練，只需使用我已經決定的技術來構建應用程序（我絕對不會說它會是完美的，只是它會起作用）。不過，我想讓我的任務更容易，這就是爲什麼我需要你的幫助。

項目

後端的簡要說明

的應用將大量數據驅動，這意味着一切都將被存儲在一個自descripting數據庫。這意味着數據庫本身將完全用元數據描述，應用程序不會知道它讀取和寫入的數據。由於應用程序不會知道數據的結構，因此不會有任何常規實體（根據JPA @ Entity）。它會從元數據中獲取它。只有元數據將具有預定的結構。簡而言之，元數據是應用程序的alpha-omega，因爲它會告訴應用程序何時顯示以及如何顯示它。

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

前端

的UI將在術語「啞」，它將不知道它正在顯示（在一定程度上，當然）的數據。它只會知道如何根據從數據庫中獲取的元數據來顯示它。所有UI控件（如菜單項，按鈕等）將根據當前應用程序的狀態創建，UI將不知道控件的功能。這意味着單擊一個菜單項或一個按鈕只會將關聯操作的標識符發送到後端，服務器將決定如何操作。

我的目標

我的主要目標是讓輕量級儘可能應用與爲最依賴越好。因爲應用程序將非常複雜，所以我想避免使用任何沉重的框架，因爲我很可能需要定製其大部分功能。

我已經決定爲

請反對以下決定只，如果你認爲他們是絕對的非可行的我的應用程序，因爲我一直在使用這些技術已經實現了一些核心功能：

• 的Servlet Tomcat上，吉斯DI，AOP（的AspectJ）
  我相信所有這些技術都足夠輕量級，我不需要學習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安全的存在;你認爲它足夠靈活供我使用，或者我會更好地實施自己的？另外，Spring的IoC是Spring框架的一個組成部分，還是我能夠繼續使用Guice？

• 其他你認爲可能有用嗎？

我真的很感激任何意見和建議，因爲我不敢嘗試自己做出這樣的決定。請問我是否需要更多信息。

預先感謝您！ eQui

Answer 1

UI框架和客戶端/服務器通信

影響你說的任何UI操作將通過靶向後端（和潛在的DB）。這意味着UI交互反而會有些緩慢，而且更重要的是需要往返服務器。

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

框架像ZK或Vaadin似乎更適合你想要什麼做。客戶端使用豐富的用戶界面有很好的小部件，但是您可以從服務器端操作用戶界面。該框架爲您管理客戶端/服務器通信（不需要REST，RPC或JavaScript）。這個框架的主要限制是可擴展性，所有這些都是往返旅行。但是，由於您的要求強加了這種無聊的行爲，您可以真正從他們提供的抽象中受益，他們在您的情況下是不是花錢。

我已經嘗試過GWT和ZK來爲我的公司做一些概念驗證。我們最終選擇了GWT，因爲它很難被嵌入到任何現有的UI中，並且很好地調整你所做的事情......尤其要儘可能避免rountrip到服務器。但ZK在發展時間方面確實更容易，速度更快。

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

DB和ORM

對於DB設計，我傾向於認爲，在DB使用細粒度的東西會使其非常非常緩慢。如果每個小部件都是數據庫中的一行或多行，則必須執行許多查找來執行最簡單的事情。

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

我知道這一點，因爲我從事的是類似（但比較簡單）的需求的一般性bug跟蹤系統，而且我們確實存在這個問題。

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

這真的很愚蠢，基本的實現是將HTML/CSS/PNG文件存儲在數據庫中，並根據需要加載它，用戶負責手工製作這些HTML文件。當然，這對用戶來說會很糟糕。這就是爲什麼你需要一個漂亮而又漂亮的編輯器UI編輯器，它可以在你自己的中間格式上工作。另一個愚蠢的實現是某種wiki模板。這不是你所需要的，你需要更多。但你有這個想法，我會尋求在這個方向......

對於維護和調試過，這將是更容易對整個UI描述了幾個文件，瞭解什麼比讀真正落實很多你最喜歡的SQL編輯器中的禁忌數據。用戶可以通過導出/導入格式輕鬆進行版本，備份或實驗。

安全

我的手說，因爲，你有用戶生成一個通用的用戶界面看起來可能是安全將是通用過於依賴和數據庫的內容。

希望它有幫助...

Answer 2

我認爲你是過度工程的解決方案。看看

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

如果一切由DB驅動，你將會有巨大的困難，使事情在UI發生，你不會是能夠使用許多工具使UI開發更容易。

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

Answer 3

對於後端，我實現了一個與數據庫有類似交互的程序。代碼是數據庫結構不知所云，而是讀取描述數據庫的配置文件，並可以根據此信息構建複雜的SQL查詢。大部分代碼是專有的，但其中的一部分被推入了一個名爲sqlbuilder的開源項目。可能對你在後臺有用。

Answer 4

我認爲你在正確的軌道上，用你的工具進行分類。您的100％數據驅動模型將難以維護。但我知道這不是一個選項。正常的源代碼管理將會失敗，因爲ui應用程序邏輯都處於元數據中。你需要一些好的測試數據庫和一些維護它們的方法，比如定期將它們mysqldump出來，並檢查它們是否能夠處理所有的差異等等。

你明智地遠離各種ORM解決方案，並只使用JDBC來處理這種類型的應用程序。

讓我給你一些關於GWT的警告。從表面上看它將抽象所有的HTML的uglyness，JavaScript的路程，爲您提供乾淨的層次結構的但 ...

1）如果抽象失敗，你怎麼方便地調試？

2）你想你的任何部位可見於谷歌或其他搜索引擎，如果是GWT是不是你

3）你想使用任何HTML5垃圾技術還是你想成爲卡在IE 5兼容模式？

所以... 我想你會好得多實施UI與一小部分與服務器的jQuery Ajax交互的簡單的HTML控件。你可以在你的數據庫中定義一個輸入類型，你的serverlet可以生成一個輸入標籤，然後你有兩個選項，你可以在jquery中有一些標準的事件綁定來告訴你的服務器button1。被點擊了，或者select2已經改變了，等等。 你的服務器可以發回javascript來改變ui的狀態 - 只需在div中加載javascript，以便它在客戶端上運行。或者2）讓輸入提交數據到服務器，然後做舊學校頁面刷新，servlet根據數據庫構建下一個ui屏幕。

與在SWING或Windows窗體中執行相同操作相比，從數據庫動態地在HTML中構建接口很容易且直接。你只需要寫出一個大的文本字符串，自1999年以來一直這樣做。

這種方法將會更輕量級 - 從長遠來看，調試，理解和修改要比隨着「GWT自動編譯爲不可讀的JavaScript，因爲某些未知原因而無法在我的瀏覽器中運行的解決方案」更簡單。