For simplicity I'll try to explain this by referring myself to only one controller, one controller action, one view, one model (domain object) and one template (file), introducing them into a User context.

Web 上描述最多的 MVC 概念 - 也由我研究過的一些流行框架實(shí)現(xiàn) - 以讓控制器控制視圖和模型的原則為中心.為了在屏幕上顯示一些東西，你必須告訴控制器——他進(jìn)一步通知視圖加載和渲染模板.如果這個(gè)顯示過程也暗示使用一些模型數(shù)據(jù)，那么控制器也會(huì)操縱模型.

The MVC concept most described on web - and also implemented by some popular frameworks that I studied - is centered around the principle of giving the controller the control over the view and the model. In order to display something on screen you'll have to tell that to the controller - he further notifies the view to load and render the template. If this display process implies the use of some model data too, then the controller manipulates the model too.

以經(jīng)典的方式，控制器創(chuàng)建和動(dòng)作調(diào)用過程包括兩個(gè)步驟:

In a classical way, the controller creation and action calling process involve two steps:

• 創(chuàng)建控制器 - 將所有依賴項(xiàng)傳遞給它，視圖包含在內(nèi)；
• 調(diào)用控制器操作.

代碼:

$controller = new UserController(/* Controller dependencies */);

$controller->{action}(/* Action dependencies */);

這意味著，控制器負(fù)責(zé)一切.所以，難怪一個(gè)控制器必須注入這么多的依賴.

This implies, that the controller is responsible for, well, everything. So, no wonder why a controller must be injected with so many dependencies.

但是控制器是否應(yīng)該參與或負(fù)責(zé)在屏幕上有效地顯示任何類型的信息?不，這應(yīng)該是視圖的責(zé)任.為了實(shí)現(xiàn)這一點(diǎn)，讓我們開始將視圖與控制器分離——從不需要任何模型的前提出發(fā).涉及的步驟是:

But should the controller be involved in, or responsible for effectively displaying any kind of information on the screen? No. This should be the responsibility of the view. In order to achieve this let's begin separating the view from the controller - going from the premise of not needing any model yet. The involved steps would be:

• 定義一個(gè) output 方法，用于在屏幕上顯示信息查看.
• 創(chuàng)建控制器 - 將所有依賴項(xiàng)傳遞給它，除了視圖及其相關(guān)依賴項(xiàng)(響應(yīng)、模板對(duì)象等).
• 創(chuàng)建視圖 - 將相應(yīng)的依賴項(xiàng)傳遞給它(響應(yīng)、模板對(duì)象等).
• 調(diào)用控制器操作.
• 調(diào)用視圖的output方法:

• Define an output method for displaying information on screen in the view.
• Create the controller - passing it all dependencies, excepting the view and its related dependencies (response, template object, etc).
• Create the view - passing it the corresponding dependencies (response, template object, etc).
• Call the controller action.
• Call the output method of the view:

和代碼:

class UserView {
    //....
    // Display information on screen.
    public function output () {
        return $this
                    ->load('<template-name>')
                    ->render(array(<data-to-display>))
        ;
    }
    //....
}

$controller = new UserController(/* (less) controller dependencies */);
$view = new UserView(/* View dependencies */);

$controller->{action}(/* Action dependencies */);
echo $view->output();

通過完成上面的五個(gè)步驟，我們?cè)O(shè)法將控制器與視圖完全分離.

By accomplishing the five upper steps we managed to completely decouple the controller from the view.

但是，有一個(gè)方面，我們之前假設(shè)過:我們沒有使用任何模型.那么控制器在這個(gè)星座中的作用是什么?答案是:沒有.控制器應(yīng)該僅作為某個(gè)存儲(chǔ)位置(數(shù)據(jù)庫(kù)、文件系統(tǒng)等)和視圖之間的中間人存在.否則，例如只是在屏幕上輸出某種格式的一些信息，視圖的output方法就完全足夠了.

But, there is an aspect, that we hypothesised earlier: we did not made use of any model. So what's the role of the controller in this constellation then? The answer is: none. The controller should exist only as a middlemann between some storage place (database, file system, etc) and the view. Otherwise, e.g. only to output some information in a certain format on screen, is the output method of the view fully sufficient.

如果模特被帶到現(xiàn)場(chǎng)，事情就會(huì)改變.但是應(yīng)該在哪里注射呢?在控制器中還是在視圖中?同時(shí).它們共享相同的模型實(shí)例.在這一刻，控制器憑借自己的權(quán)利獲得了中間人的角色——介于存儲(chǔ)和視圖之間.一種理論形式是:

Things change if a model is beeing brought on the scene. But where should it be injected? In the controller or in the view? In both. They share the same model instance. In this moment the controller gains the role of the middleman - between storage and view - in his own right. A theoretical form would be:

$model = new UserModel;
$controller = new UserController($model, /* Other controller dependencies */);
$view = new UserView($model, /* Other view dependencies */);

$controller->{action}(/* Action dependencies */);
echo $view->output();

這樣做，控制器可以改變模型的狀態(tài)并確保它保存在存儲(chǔ)系統(tǒng)中.視圖讀取并顯示相同的模型實(shí)例及其狀態(tài).控制器通過模型將顯示邏輯信息傳遞給視圖.問題是，這些信息不屬于模型應(yīng)該專有的業(yè)務(wù)邏輯.他們只是顯示邏輯參與者.

Doing so, the controller can change the state of the model and ensure that it's saved in the storage system. The same model instance, respective its state, is read by the view and displayed. The controller passes display logic informations to the view through the model. The problem is, that these informations don't belong to the business logic, which a model is supposed to exclusively have. They are only display logic participants.

為了避免將顯示邏輯責(zé)任交給模型，我們不得不在圖中引入一個(gè)新組件:view-model.控制器和視圖將共享一個(gè)視圖模型實(shí)例，而不是共享模型對(duì)象.只有這個(gè)將接收模型作為依賴項(xiàng).一個(gè)實(shí)現(xiàn):

In order to avoid giving display logic responsibilities to the model, we have to introduce a new component in the picture: the view-model. Instead of sharing a model object, the controller and the view will share a view-model instance. Only this one will receive the model as dependency. An implementation:

$model = new UserModel;
$viewModel = new UserViewModel($model, /* Other view-model dependencies */);
$controller = new UserController($viewModel /* Other controller dependencies */);
$view = new UserView($viewModel, /* Other view dependencies */);

$controller->{action}(/* Action dependencies */);
echo $view->output();

工作流程可以這樣描述:

And the workflow can be described like this:

• 請(qǐng)求值由瀏覽器(用戶")發(fā)送到控制器.
• 控制器將它們作為屬性存儲(chǔ)在視圖模型實(shí)例中(數(shù)據(jù)成員)，因此改變了顯示邏輯狀態(tài)視圖模型.
• 在其 output 方法中，視圖從視圖模型并請(qǐng)求模型查詢其上的存儲(chǔ)
• 模型運(yùn)行相應(yīng)的查詢并將結(jié)果傳回給視圖.
• 視圖讀取并將它們傳遞給相應(yīng)的模板.
• 模板渲染后，結(jié)果顯示在屏幕上.

• The request values are sent by the browser ("the user") to the controller.
• The controller stores them in the view-model instance as properties (data members), therefore changing the display logic state of the view-model.
• Within its output method, the view reads the values from the view-model and requests the model to query the storage on their basis.
• The model runs the corresponding query and passes the results back to the view.
• The view reads and passes them to the corresponding template.
• After template rendering, the results are displayed on the screen.

視圖模型不屬于域模型，所有域?qū)ο蠖捡v留在域模型中，真正的業(yè)務(wù)邏輯發(fā)生在域模型中.它也不屬于操作域?qū)ο蟆⒋鎯?chǔ)庫(kù)和數(shù)據(jù)映射器的服務(wù)層.它屬于應(yīng)用程序模型，例如應(yīng)用程序邏輯發(fā)生的地方.視圖模型獲得從控制器獲取顯示邏輯狀態(tài)并將其傳遞給控制器??的唯一責(zé)任.

The view-model does not belong to the domain model, where all domain objects reside and the real business logic takes place. It does also not belong to the service layer, which manipulates the domain objects, repositories and data mappers. It belongs to the application model, e.g to the place where the application logic takes place. The view-model obtains the sole responsibility of gaining display logic state from the controller and conducting it to the controller.

可以看出，只有視圖模型接觸"了模型.控制器和視圖不僅彼此完全解耦，而且還與模型完全解耦.這種方法最重要的方面是，所涉及的所有組件中的每一個(gè)都只獲得它應(yīng)該獲得的職責(zé).

As can be seen, only the view-model "touches" the model. Both, the controller and the view were not only completely decoupled from each other, but also from the model. The most important aspect of this approach is, that each of all the components involved gains only the responsibilities, that it is supposed to gain.

通過使用這種組件分離和依賴注入容器，控制器依賴過多的問題消失了.并且可以以一種非常靈活的方式應(yīng)用我的問題中提出的所有選項(xiàng)的組合.無需考慮其中一個(gè)組件(模型、視圖或控制器)承擔(dān)了太多責(zé)任.

By making use of this kind of component separation and of a dependency injection container, the problem of too many dependencies in controllers vanishes. And one can apply a combination of all options presented in my question in a really flexible manner. Without having in mind that one of the components (model, view or controller) gains too many responsibilities.

這篇關(guān)于PHP MVC:控制器中的依賴項(xiàng)太多?的文章就介紹到這了，希望我們推薦的答案對(duì)大家有所幫助，也希望大家多多支持html5模板網(wǎng)！