2013-02-03 39 views
0

我有一個網站,其中有一個企業的多個應用程序存在。 他們共有多個模型,但每個模型都有明確的功能區分。例如,其中一個應用程序允許用戶爲客戶進行產品報價。另一個應用程序是購物車。另一個是跟蹤產品。 他們爲不同的受衆做了不同的事情,但他們都使用產品和用戶模型等等。建築選擇:如何處理一個網站中的多個應用程序

我的問題是,與像笨的PHP或RoR的框架工作時,什麼是最好的架構決策:

  1. 僅生成一個與塞到 它的所有功能應用。

  2. 構建多種應用程序和處理常用模型和 庫在一個 「主應用程序」(我的選擇)

謝謝!

回答

1

我們也在使用相同的場景。我們的解決方案在.NET中,但技術不是需要擔心的問題,至少在大多數情況下。

我們常見的應用程序組件是:客戶帳戶管理,購物車和身份驗證模型,共享3個不同的客戶端Web應用程序。有幾種方法可能需要調查以解決此問題。目標是在您的所有網站上共享通用組件。

我們選擇的方法是讓我們所有的應用程序共享相同的代碼庫。我們從所有三個應用程序中提取客戶帳戶管理,購物車和身份驗證模型,並首先創建一個通用代碼庫。關鍵是要確保公共共享模型不知道使用它服務的應用程序。在某些情況下,我們使用特定於應用程序的注入,但主要公共組件大部分只關心哪個應用程序數據庫寫入其他常見但不同的應用程序數據庫。

缺點是每個應用程序都有自己的二進制文件,因此當運行在同一個Web服務器上時,加載到內存中的代碼是每個應用程序加載相同公共模型的三倍。但這是我們知道的價格,因爲現在的記憶日子非常便宜。

好處是我們有共同的問題分離,如果在某些時候應用程序變得足夠不同,他們可以演變成不同的動物。

另一種方法是將通用模型分爲網絡服務。但是從部署的角度來看,這種方法有點嚇人。

我希望這有助於!

+0

因此,基本上共同的基本代碼就是我們稱之爲所有應用程序共享的「主應用程序」或「核心組件」。 另一個缺點是,例如,框架更新。我們必須仔細更新每個應用程序內的每個框架代碼。 但對我來說,這個選擇的優點是比缺點更有意義。 這個我發現它非常有幫助: *「關鍵是要確保普通的共享模型不知道使用它服務的應用程序」* 謝謝! – atoledo

0

對於RoR,您應該研究創建在應用程序之間共享的寶石。這將允許您選擇這些組件的哪些組合用於這些客戶端。

你可以看到的另一件事是發動機,它就像一個應用程序內的應用程序 - http://guides.rubyonrails.org/engines.html - 這個頁面給你一個如何使用它的例子。

+0

是的,我會研究它。 我發現Ruby on Rails是一個更加複雜和智能的框架 – atoledo

相關問題