Re: [心得] 框架不應該有「MODELS」資料夾

[lance70176 (十三夜)]

原文恕刪

其實是我建議原作者把這篇文章轉來討論的

只是工作一忙就沒時間來參與

現在放假不寫 code 來補寫文章

個人使用過的 MVC framework 有

Cake PHP 2.0 (入門級)
CI N年前版本 (入門級)
ASP.Net MVC 2.0 (大型網站開發)
ASP.Net MVC 4.0 (獨立網站開發)
Laravel 4.2 (大型網站開發)


以我的觀點來看 目前市面上所謂的 MVC framework

其實都不是單純的 MVC，而是包含了各式各樣的變種

可能像是 MVVM MVP 或是各式各樣大家自己不同的作法

比如說原作者認為把邏輯層塞到 Model 是很蠢的事情

但是也有推文說出了解決的做法

比如說有幾個推文看法跟我一樣

→ motestg: MVC架構,有多種解釋,不過這種Model還是第一次見過,超詭異
推 ROCKandROLL: 我是把 model 當作 database 的 interface
噓 takasaki: ....我都爽叫models,我還會開repository service等等

以上這些不同看法 導致了一個結果

你的 MVC 不等於我的 MVC

作者：哈哈哈 你的 Model 好肥啊

版眾：你連 Model 在哪都不知道

好吧 雖然大家有分歧 但是總有一個問題是一樣的

就是我現在使用的框架，架構合理嗎？

用下面幾個例子來看


1.小型專案 (ex:活動案)

這些活動案幾乎沒什麼邏輯

省下你的controller吧

寫一行 return view 其實沒什麼意義

可能會有極少部分邏輯的地方

把這部分功小小的獨立出來

那就可以看成是 VM 架構


2.中型專案 (ex:文章網站）

中型網站有最多的選擇，包含了各種變種

不過反正現在大家都是統整成一句 MVC 架構

把邏輯放在 Model, Controller, Service?

其實最大差別不過就是 定義邏輯的分佈方式而已


3.大型網站 (ex:大型購物網站)

這部分設計其實跟產業還有功能上的要求有很大關連

比較難一概括之 我遇過大型購物網站當年是硬建立起來的

邏輯分散各處 混雜了各種結構

因為真的動不了所以最後只好把所有動不了的部分包起來當成底層

使用ＡＰＩ呼叫, 未來修改盡量不動底層的部分

不過現在的大型網站大多會把邏輯拆開重整

除了前面說的多了repository service

甚至可以把 Model 部分整合成一個專案

或是一些特殊且可以分離的地方獨立成新專案

比如說風險控管，使用者折價券...等

當然是否能拆成漂亮又是另外一回事

但是至少好過大家黏在一起 你中有我 我中有你

P.S.
本來想把大型網站的經驗列出來 但是實在太細又冗長

不適合在這細說 請大家原諒我寫的這麼攏統ＸＤ



我是認為沒必要去苛求所謂的框架一定要符合定義

MVC 是個入門的概念，雖然細節不是全對但是大方向是正確的

過多的追求不過是找麻煩而已

當你跨過某個階段你可以說它的定義不精確沒錯

但是糾正全天下其實一點幫助也沒有

反而讓那些剛入門的人 嚇到退出去而已

以上一點拙見 請大家指教

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.161.49.248
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1428053706.A.9F4.html
※ 編輯: lance70176 (1.161.49.248), 04/03/2015 17:43:03
→ lovdkkkk: 呃...不, 個人覺得 MVC 要變種成 MVVM 蠻不容易的
→ lovdkkkk: JMF 就是超像 MVVM 的 MVC, 可是還是 MVC XD
→ lovdkkkk: 更正, JMF -> JSF
推 sing10407: 推推
推 pttworld: 推，別嚇新手。
→ snaketsai: Pattern本來就不是硬套的東西... 只是概念罷了
推 amazing2014: 推，我也覺得只是概念，個人想法不同，not my type
推 ntddt: 推 各種招都有適用的情境 但怎套到最適合的是學問~
推 Masakiad: 會爭論這些是沒先搞懂什麼是design pattern，跟design p
→ Masakiad: attern的用途。然後pattern確實是概念，跟最近很紅的scr
→ Masakiad: um一樣