企業Web應用程序體系結構問題

Question

我想知道是否有可能通過將業務/流邏輯和會話數據傳遞到客戶端大小的Javascript並使其與REST數據進行通信而無需使用標准MVC結構和應用服務器來開發企業級Web應用程序直接服務...也許我們可以利用位於數據服務之上的授權/身份驗證層和第二個驗證層。 所有這些服務都在標准HTTP方法上運行，支持可配置的日志記錄和監視，並且內容或查詢參數都包含在HTTP請求/響應主體中。 靜態HTML和Javascript提供給瀏覽器，其余的則由Javascript函數執行，這些函數與基於HTTP的授權/身份驗證，驗證以及數據服務進行通信。 您認為這種架構可以滿足企業級Web應用程序要求嗎？

Answer 1

它可能但不太可能； 有哪些驅動程序向您建議該架構？ 只是有所不同還是最能解決某些特定方面？

通過將業務/流邏輯和會話數據傳遞到客戶端Javascript，並使其直接與REST數據服務對話

從理論上講，您仍然可以擁有一個適當的分層解決方案（Business Logic（BL）腳本與針對UI的腳本），但實際上它會很混亂。 並且您將失去將其物理上划分為不同層的能力。 這可能會在系統壽命中的任何地方“咬住”您。

“企業”級別的系統很少這么小，我討厭考慮您必須通過有線方式發送多少邏輯來支持給定的操作/流程。

將所有BL放入腳本語言后，您便會與該平台建立聯系，並且平台會隨着時間的推移而變化。 關於腳本的壞處是，盡管它們在一定程度上是穩定的，但我建議它們比基於Java或.Net的基於服務器的平台更容易受到更改的影響。 在企業場景中，服務器將具有非常嚴格的變更控制和為其映射的升級路徑-因為瀏覽器更易於進行定期變更。

存在兼容性問題-除非您綁定到特定的瀏覽器（在版本級別），否則要保證一致的行為將變得更加困難，並且可能需要更多的開發工作。 假設您成功交付了解決方案； 當企業希望利用移動計算（例如iPad）時，您會怎么做？ 您唯一的選擇將是瀏覽器-您將無法利用該平台的任何本機優勢。 “網絡和瀏覽器”似乎永遠存在-但是我猜測MainFrame當時所說的話。 以服務器為中心的解決方案將以更少的費用為您提供更多的使用壽命。

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

安全性：將核心BL暴露在暴露得多的客戶端上非常危險。

編輯：

可以播種Web Apps的原因有很多-沒什么理由足以將您所有的BL放在客戶端的JavaScript中。 為性能而構建應用程序是一個整體的工作領域-我建議您在完全注銷n層Web應用程序之前更加熟悉為性能設計和實施：)

關於將各層分開：有不同的方法，但可以歸結為抽象-更准確地說，是要牢記好的設計原則。 如果您還沒有聽說過SOLID ，那將是一個不錯的起點。 在實現方面，開始閱讀Dependency Inversion （FYI-自我提升，這些文章屬於我，並且是.Net的，但您也應該不會遇到基於Java的問題）。