javascript - 說說現在的系統架構該怎麼分層好？

最近接手了一個別人的項目。發現大家都MVC架構真的運用的爐火純青啊。幾乎所有的邏輯都寫在C層？

• 是不是你的項目也遇到這樣的問題呢？

• MVC真的夠麽?

• Service層用到的多麽？

update

至少我認為，C層保持清晰的邏輯和簡單的變數初始化即可，所有的detail邏輯都不應該在c層，我的意思是，最複雜的控制中樞也只會有複雜的按鈕而已，不要把製造按鈕的原材料堆滿在這裡。

回複內容：

最近接手了一個別人的項目。發現大家都MVC架構真的運用的爐火純青啊。幾乎所有的邏輯都寫在C層？

• 是不是你的項目也遇到這樣的問題呢？

• MVC真的夠麽?

• Service層用到的多麽？

update

至少我認為，C層保持清晰的邏輯和簡單的變數初始化即可，所有的detail邏輯都不應該在c層，我的意思是，最複雜的控制中樞也只會有複雜的按鈕而已，不要把製造按鈕的原材料堆滿在這裡。

脫離業務談架構都是耍流氓

系統架構是靈活的，根據需求的不同，不一定每一層的技術都需要使用

必須不夠,不僅有 Service 層,還有 Business 層.

個人認為絕大多數情況下，薄C厚M是優於厚C薄M的

“Service層” 如果也還是PHP代碼的話，我認為說面源自MVC的一個經典誤讀：把MVC中的Model層等價於資料庫抽象的ORM或DAO

換個問法，如果有個項目不用mysql或其它關聯式資料庫存資料，難道就不能MVC了？
比如弄個純文字儲存的wiki項目，就寫不出MVC了？

一般來講，MVC比起應對需求變更，更重要的時候為了測試。而且MVC是一個抽象概念，而不是一個具體的概念，所以MVC中的這三部分的內部也可以有MVC。

就用Segmentfault來講，每一個頁面可以是一個View。如果網站支援多語言的話，那麼顯示中文和英文的區別就是在View裡面做的。而排序功能你可以選擇做在Controller。因此對於大部分的功能測試，你完全可以不渲染網頁，而直接存取Controller來解決。

功能相近的View也可以共用Controller。就像你可以看到一個問題+答案的頁面，也可以看到只有答案的頁面一樣。顯然區別只是在於有沒有渲染問題，那麼使用同一個Controller是沒有問題的。

而若干個Controller可以使用同一個Model。Model並不一定是資料庫，他也可以是資料庫的封裝，從而Model裡面還有自己的MVC。

不過這些東西抽象的太厲害，導致MVC在開發過程中的指導意義也不那麼重要了。

