国产av日韩一区二区三区精品,成人性爱视频在线观看,国产,欧美,日韩,一区,www.成色av久久成人,2222eeee成人天堂

不得不頂一下易偉的說法 ，我補充下我的理解，V為保證用戶體驗而做校驗，不至于讓用戶提交之后發(fā)現(xiàn)出錯了在回去改，C為保證數(shù)據(jù)本身的合法性而校驗（數(shù)據(jù)是否屬于該用戶，數(shù)據(jù)狀態(tài)改變是否符合邏輯要求），M為保證數(shù)據(jù)存在性而交易，數(shù)據(jù)都不存在，下面的都不用走了，肯定是異常了。

這個問題需要結合具體應用、具體語言、具體框架分析，甚至和團隊成員的風格、構成有關。

我個人傾向于M做校驗邏輯，拋異常，然后C捕捉并轉換為前端需要的格式輸出。這樣初期代碼可能啰嗦一點，但對邏輯完整性和后期擴展比較有利。

還有一種做法是在M和C中間建立一層所謂邏輯層，來處理校驗邏輯和部分業(yè)務邏輯

一般MVC框架中會根據(jù)業(yè)務處理增加一層service層，model做ORM映射或者直接拋棄，寫個DAO，好了，現(xiàn)在來說下校驗到底在哪層里面做，最正確的方法是控制器層C和服務層S都要做，因為隨著網(wǎng)站發(fā)展，肯定是需要將service單獨拎出來，做為公共的服務組件，進行遠程調(diào)用，所以如果你不在控制器層做校驗的話，今后有數(shù)據(jù)請求，你直接丟給公共的服務，如果數(shù)據(jù)有問題，然后再返回錯誤，這很明顯就浪費了一次網(wǎng)絡IO,所以如果你已經(jīng)在控制器層面做好數(shù)據(jù)校驗了，當數(shù)據(jù)有誤，直接拋出異常，不需要再通過RPC取進行一次遠程調(diào)用了

這絕對要分情況看的：

• 文本格式的合法性：在前端用js驗證或正則表達式處理掉就好。
• 數(shù)據(jù)的有效性問題：
  
  
  • 簡單情況：比如驗證年月日的合法性，同樣可以放在前端來做。
  • 更廣泛的情況：包含以上兩種情況，也包含用戶名驗證、重復性驗證等，牽扯具體業(yè)務邏輯的情況，以Rails框架為代表，是放在Model中完成驗證的。

Fat model, skinny controller.

鵝廠編碼有個原則：接口間互不信任。

不用任何框架自己寫的話應該屬于c層。但是更多的框架傾向于放在m層里面。

另外不要只在v層做輸入校驗，前端的東西很容易被繞過，有安全隱患。

每一層都要做，側重點不同。

我們一般在MVC的C-M之間一定會再加一層Service層(不過也可以理解成是C或M的一部分)，這一層是設計為與View和Controller解耦，可以獨立剝離出來給外部調(diào)用的(API)。

所以，
在View里面，進行比較弱的單個值的合法性校驗，
在Controller里面，做外部來的請求數(shù)據(jù)包的合法性校驗和部分用戶接口權限校驗；
在Service里面做嚴格的數(shù)據(jù)合法性校驗、業(yè)務邏輯約束校驗、用戶數(shù)據(jù)權限校驗；
在Model里面做數(shù)據(jù)的物理合法性校驗。

如果題主使用過Python的Django或者Flask這樣的框架的話，會發(fā)現(xiàn)還有一個Form類。用戶內(nèi)容驗證的邏輯，一般來說會放在Form類里面來做。因為有時候，我們可能需要根據(jù)不同的情況，針對同一個Data model做不同的驗證規(guī)則。當然Django也支持Model層的驗證。相對而言。Form層來做這個，耦合度更低一點。

簡單的MVC一般會把FORM驗證做在model層上，而比較成熟的方案一般會把FORM分出來，以joomla為例，它有FORM層并整合到model層上，結構上是屬于model層，但功能的實現(xiàn)又似乎跟model層沒什么關系。

其實合法性檢查也分本地和服務器端。
例如輸入為空，是放在 V 層來檢查；輸入的格式不對事放在 M 層來檢查。
如果要進一步檢查是否合格更是放在 M 層通過訪問服務器來檢查。