企業Web應用程序架構問題

Question

我想知道是否可以通過將業務/流邏輯和會話數據傳輸到客戶端大小而不使用標準MVC結構和應用程序服務器來開發企業級Web應用程序Javascript並使其直接與REST數據服務交談......也許我們可以利用位於數據服務之上的授權/驗證層和第二個驗證層。所有這些服務都使用標準HTTP方法進行操作，支持可配置的日誌記錄監視，並且內容或查詢參數都包含在HTTP請求/響應正文中。向瀏覽器提供靜態HTML和Javascript，其餘部分通過與基於HTTP的授權/驗證，驗證和數據服務通話的Javascript函數執行。您認爲這種架構可以滿足企業級Web應用程序的需求嗎？

Answer 1

它可能但不太可能;爲你提供這種架構的驅動因素是什麼？它只是爲了不同，還是有一些具體的方面，這最好的地址？

所搭載的業務/流邏輯 和會話數據到客戶端 Javascript和使它跟REST直接

數據服務在理論你仍然能有一個適當的分層解決方案（業務邏輯（BL）腳本vs用戶界面焦點腳本），但實際上它會是混亂的;而且你會失去把它分成不同層次的能力。這可能會在系統生命週期的任何地方「咬」你。

「企業」等級的系統很少，我討厭考慮你需要通過網絡發送多少邏輯來支持給定的動作/過程。

把所有的BL都變成一種腳本語言將你與該平臺聯繫起來，而且平臺會改變加班。腳本的壞處在於，雖然它們在一定程度上穩定，但我認爲它們比基於服務器的平臺（如Java或.Net）更容易受到變化影響。在企業場景中，服務器將具有非常緊湊的變更控制和升級路徑 - 因爲瀏覽器對定期更改更加開放。

存在兼容性問題 - 除非你綁定到特定的瀏覽器（到版本級別），否則保證一致的行爲將變得更加困難，並且可能需要更多的開發工作。假設您成功交付解決方案;當企業想要利用移動計算 - 例如iPad時，你會做什麼？你唯一的選擇就是成爲瀏覽器 - 你將無法利用平臺的任何本地優勢。 「網絡和瀏覽器」看起來可能會永遠存在 - 但後來我猜測MainFrame當時所說的是什麼。以服務器爲中心的解決方案將爲您節省更多的生命。

人員配置將是一個問題 - 您需要非常強大的JavaScript和服務器端開發人員。

安全性：讓您的核心BL出現在客戶端，暴露得更多時聽起來非常危險。

編輯：

Web應用程序可以播種的原因有很多 - 這不是很多都是足夠的理由把所有您的BL在JavaScript在客戶端上。構建性能應用程序本身就是一個努力的全部領域 - 我建議您在完成註銷n-tier Web應用程序之前更熟悉架構和性能實現:)

關於保持圖層分離：有不同的方式來做這件事，但它歸結爲抽象 - 更正確地記住保持良好的設計原則;如果你還沒有聽說過SOLID這將是一個很好的開始。在實施方面開始閱讀Dependency Inversion（僅供參考 - 自我推廣，這篇文章是我的重點，但你也應該沒有問題跟蹤基於Java的文章）。