Yii2.0框架 MVC 最佳實踐

keithxiaoy 發布于2019-06-28 18:47 / 477人閱讀

摘要：框架最佳實踐最佳實踐在設計良好的應用中，控制器很精練，包含的操作代碼簡短如果你的控制器很復雜，通常意味著需要重構，轉移一些代碼到其他類中。層業務邏輯層框架由，，組成，執行流程一般是在訪問獲取數據，通過渲染頁面。

Yii2.0框架 MVC 最佳實踐 Controller最佳實踐

在設計良好的應用中，控制器很精練，包含的操作代碼簡短； 如果你的控制器很復雜，通常意味著需要重構， 轉移一些代碼到其他類中。

控制器職責 1. 可訪問請求數據

// GET參數
$get = Yii::$app->getRequest()->get();
$get = Yii::$app->getRequest()->getQueryParams();
// POST參數
$post = Yii::$app->getRequest()->post();
$post = Yii::$app->getRequest()->getBodyParams();

2. 可根據請求數據調用模型的方法和其他服務組件

$searchModel = new ArticleSearch();
$dataProvider = $searchModel->search(Yii::$app->request->queryParams);

$websiteKv = Website::kv("id", "title");

$model = $this->findModel($id);
$model->load(Yii::$app->request->post());
$model->save()

3. 可使用視圖構造響應

return $this->render("edit", [
    "model" => $model,
    "subjectKv" => $subjectKv
]);

4. 不應處理應被模型處理的請求數據

例如，將表單提交的 Y-m-d 時間格式轉換為時間戳等，放到模型中進行處理。

5. 應避免嵌入HTML或其他展示代碼，這些代碼最好在視圖中處理 Model最佳實踐

模型是代表業務數據、規則和邏輯的中心地方，通常在很多地方重用， 在一個設計良好的應用中，模型通常比 控制器代碼多。

模型職責 1. 可包含屬性來展示業務數據

主要是數據表字段映射到模型類中的屬性，可適當增加自定義public屬性。

2. 可包含驗證規則確保數據有效和完整

rules() 方法等

3. 可包含方法實現業務邏輯

public function getSubject()
{
    return $this->hasOne(Subject::className(), ["sid" => "sid"]);
}

public function getMedia()
{
    return $this->hasMany(ArticleMedia::className(), ["aid" => "aid"]);
}

public function updateStatus($status)
{
    return $this->updateAttributes(["status" => $status]);
}

4. 不應直接訪問請求，Session和其他環境數據，這些數據應該由控制器傳入到模型

不允許使用任何 Yii::$app->getRequest() 下的方法，只可在控制器中使用。

5. 應避免嵌入HTML或其他展示代碼，這些代碼最好在視圖中處理 6. 單個模型中避免太多的場景

在開發大型復雜系統時應經常考慮這條建議，在這些系統中，模型會很大并在很多地方使用，因此會包含需要規則集和業務邏輯，最后維護這些模型代碼成為一個噩夢，因為一個簡單修改會影響好多地方，為確保模型好維護，最好使用以下策略。

定義可被多個應用主體或模塊共享的的模型基類集合。這些模型類應包含通用的最小規則集合和邏輯。

在每個使用模型的應用主體或模塊中，通過繼承對應的模型基類來定義具體的模型類，具體模型類包含應用主體或模塊指定的規則和邏輯。

例如，在高級應用模板，你可以定義一個模型基類 commonmodelsPost，然后在前臺應用中，定義并使用一個繼承 commonmodelsPost 的具體模型類 frontendmodelsPost，在后臺應用中可以類似地定義 backendmodelsPost。通過這種策略，你清楚 frontendmodelsPost 只對應前臺應用，如果你修改它，就無需擔憂修改會影響后臺應用。

View最佳實踐

視圖負責將模型的數據展示用戶想要的格式

視圖職責 1. 應主要包含展示代碼，如HTML, 和簡單的PHP代碼來控制、格式化和渲染數據 2. 不應包含執行數據查詢代碼，這種代碼放在模型中

當在 GridView 中感覺需要使用數據庫查詢時，首先要想一想通過聯表（with(),joinWith()）是否能替代該查詢。若能，則使用聯表；若不能，可適當使用數據查詢。

3. 應避免直接訪問請求數據，如 $_GET, $_POST，這種應在控制器中執行，如果需要請求數據，應由控制器推送到視圖 4. 可讀取模型屬性，但不應修改它們 5. 為使模型更易于維護，避免創建太復雜或包含太多冗余代碼的視圖，可遵循以下方法達到這個目標：

使用布局來展示公共代碼（如，頁面頭部、尾部）；

將復雜的視圖分成幾個小視圖，可使用上面描述的渲染方法將這些小視圖渲染并組裝成大視圖；

創建并使用小部件作為視圖的數據塊；

創建并使用助手類在視圖中轉換和格式化數據。

Service層（業務邏輯層）

MVC框架由Model，View，Controller組成，執行流程一般是：在Controller訪問Model獲取數據，通過View渲染頁面。

MVC模式是Web開發中的基礎模式，采用的是分層設計，各層之間職責分明。然而事與愿違，當我們日積月累的基于MVC模式開發之后，會逐漸的感受到層與層之間存在粘連和職責模棱兩可的地方，這就是Service層出現的重要原因。

Yii2框架建議將大部分業務邏輯放到模型類中，當業務邏輯比較簡單時，這樣確實能使代碼結構清晰，又增加了代碼的復用率。但是在開發大型復雜系統時，業務邏輯會比較復雜，模型類的代碼量會非常大，通常又會涉及到多個模型類，增大了模型類之間的耦合，不利于維護。

Service職責 1. 對模型類進行解耦

把需要多個model參與的復雜業務邏輯多帶帶封裝出來，這些model之間不再發生直接的依賴，而是在Service層內協同完成邏輯。

2. 簡化模型類的業務邏輯

模型類應該只處理簡單的業務邏輯，當方法的業務邏輯比較復雜時（例如一些統計功能的靜態方法等），建議將該業務邏輯放到Service層處理。

GPU云服務器云服務器最佳實踐 webrtc最佳實踐 cdn最佳實踐 vpc最佳實踐

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/28658.html

【譯】前端練級攻略

摘要：由于系統變得越來越復雜，人們提出了稱為預處理器和后處理器的工具來管理復雜性。后處理器在由預處理器手寫或編譯后對應用更改。我之前建議的文章，，也涵蓋了預處理器相關的知識。譯者：前端小智原文：medium.freecodecamp.org/from-zero-t… medium.freecodecamp.org/from-zero-t… 我記得我剛開始學習前端開發的時候。我看到了很多文章及...

wuyumin 2019-05-22 16:41 評論0 收藏0
[譯] 前端攻略-從路人甲到英雄無敵二：JavaScript 與不斷演化的框架

摘要：一般來說，聲明式編程關注于發生了啥，而命令式則同時關注與咋發生的。聲明式編程可以較好地解決這個問題，剛才提到的比較麻煩的元素選擇這個動作可以交托給框架或者庫區處理，這樣就能讓開發者專注于發生了啥，這里推薦一波與。本文翻譯自FreeCodeCamp的from-zero-to-front-end-hero-part。繼續譯者的廢話，這篇文章是前端攻略-從路人甲到英雄無敵的下半部分，在...

roadtogeek 2019-08-19 18:25 評論0 收藏0
前端練級攻略(第二部分)

摘要：是文檔的一種表示結構。這些任務大部分都是基于它。這個實踐的重點是把你在前端練級攻略第部分中學到的一些東西和結合起來。一旦你進入框架部分，你將更好地理解并使用它們。到目前為止，你一直在使用進行操作。它是在前端系統像今天這樣復雜之前編寫的。本文是前端練級攻略第二部分，第一部分請看下面：前端練級攻略(第一部分) 在第二部分，我們將重點學習 JavaScript 作為一種獨立的語言，如...

BWrong 2019-08-23 16:49 評論0 收藏0
Android架構 - 收藏集 - 掘金

摘要：代碼不會寫的很復雜架構思考模塊化多進程掘金關于模塊化組件化這個問題，我想每個開發者可能都認真的思考過。今天，我安居客項目架構演進掘金本文已授權微信公眾號獨家發布。關于 Dagger2+Mvp+rxjava+retroft2.0 的一點實踐 - Android - 掘金前言做這個項目的初衷是想練手，因為現在rxjava+retrofit框架相當火，而公司的同事正在用這個框架也覺得很方便...

honmaple 2019-06-24 17:54 評論0 收藏0