blocks|key|2319368|text|据我所知，Controller从用户界面操作转换为应用程序级操作。例如，在电子游戏中，控制器可能会将“移动鼠标这么多像素”转换为“想要朝这样和那样的方向看”。在CRUD应用程序中，翻译可能会“点击这样和那样的按钮”，以“打印这个东西”，但概念是一样的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2319369|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

As I understand it, the Controller translates from user-interface actions to application-level actions. For instance, in a video game the Controller might translate "moved the mouse so many pixels" into "wants to look in such and such a direction. In a CRUD app, the translation might be "clicked on such and such a button" to "print this thing", but the concept is the same.

blocks|key|2319382|text|下面是一个关于MVC基础的好文章。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2319383|上面说..。|2319384|控制器-控制器将与视图的交互转换为由模型执行的操作。|blockquote|2319385|换句话说，你的业务逻辑。控制器响应用户在视图中采取的操作并作出响应。您可以将验证放在这里，如果验证失败或成功，则选择适当的视图(错误页、消息框等)。|2319386|还有一个很好的Fowler的文章。|2319387|entityMap|0|LINK|mutability|MUTABLE|url|https://web.archive.org/web/20090805073932/http://java.sun.com/blueprints/patterns/MVC-detailed.html|1|http://www.martinfowler.com/eaaDev/uiArchs.html#ModelViewController^0|D|3|0|0|0|0|0|7|9|1|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@$A|X|B|Y|1|Z]]|C|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|11|8|@]|9|@]|C|$]]|$1|I|3|J|5|6|7|12|8|@]|9|@]|C|$]]|$1|K|3|L|5|6|7|13|8|@]|9|@$A|14|B|15|1|16]]|C|$]]|$1|M|3|-4|5|6|7|17|8|@]|9|@]|C|$]]]|N|$O|$5|P|Q|R|C|$S|T]]|U|$5|P|Q|R|C|$S|V]]]]

Here is a <a href="https://web.archive.org/web/20090805073932/http://java.sun.com/blueprints/patterns/MVC-detailed.html" rel="noreferrer">good article</a> on the basics of MVC. 

It states ...

<blockquote>
 Controller - The controller translates
 interactions with the view into
 actions to be performed by the model.
</blockquote>

In other words, your business logic. The controller responds to actions by the user taken the in the view and responds. You put validation here and select the appropriate view if the validation fails or succeeds (error page, message box, whatever).

There is another good <a href="http://www.martinfowler.com/eaaDev/uiArchs.html#ModelViewController" rel="noreferrer">article at Fowler</a>.

blocks|key|928835|text|在您建议的示例中，您是正确的：“用户单击了界面中的‘删除此项’按钮”，应该只需调用控制器的“删除”函数即可。然而，控制器不知道视图是什么样子，所以您的视图必须收集一些信息，例如“单击了哪个项？”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|928836|以谈话的形式：|928837|View：“嘿，控制器，用户刚刚告诉我他希望删除第4项。”|offset|length|style|BOLD|928838|Controller：“嗯，在检查了他的凭据之后，他被允许这么做了.嘿，模型，我想让你得到第4项，做任何你做的事情来删除它。”|928839|Model：“第4项.明白了。它被删除了。还给你，控制器。”|928840|Controller：“在这里，我将收集新的数据集。回到您，查看。”|928841|View：“酷，现在我将向用户展示新的设置。”|928842|在这一节的末尾，您有一个选项:视图可以发出单独的请求，“给我最新的数据集”，因此更纯净，或者控制器隐式地返回带有"delete“操作的新数据集。|928843|entityMap^0|0|0|0|4|0|0|A|0|0|5|0|0|A|0|0|4|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@$F|Y|G|Z|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|10|8|@$F|11|G|12|H|I]]|9|@]|A|$]]|$1|L|3|M|5|6|7|13|8|@$F|14|G|15|H|I]]|9|@]|A|$]]|$1|N|3|O|5|6|7|16|8|@$F|17|G|18|H|I]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|19|8|@$F|1A|G|1B|H|I]]|9|@]|A|$]]|$1|R|3|S|5|6|7|1C|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|U|$]]

In the example you suggested, you're right: "user clicked the 'delete this item' button" in the interface should basically just call the controller's "delete" function. The controller, however, has no idea what the view looks like, and so your view must collect some information such as, "which item was clicked?"

In a conversation form:

View: "Hey, controller, the user just told me he wants item 4 deleted." 
Controller: "Hmm, having checked his credentials, he is allowed to do that... Hey, model, I want you to get item 4 and do whatever you do to delete it." 
Model: "Item 4... got it. It's deleted. Back to you, Controller." 
Controller: "Here, I'll collect the new set of data. Back to you, view." 
View: "Cool, I'll show the new set to the user now."

In the end of that section, you have an option: either the view can make a separate request, "give me the most recent data set", and thus be more pure, or the controller implicitly returns the new data set with the "delete" operation.

blocks|key|795026|text|控制器主要用于视图和模型之间的协调。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|795027|不幸的是，它有时会和视图混在一起--在小应用程序中--尽管这并不是太糟糕。|795028|我建议你把：|795029|public+void+actionPerformed(ActionEvent+e)|code-block|syntax|javascript|795030|在控制器里。然后，您的视图中的动作侦听器应该委托给控制器。|795031|至于验证部分，您可以将其放在视图或控制器中，我个人认为它属于控制器。|795032|我肯定会建议看一看被动视图并监督演示者(这基本上就是Model演示者被分成的部分--至少由Fowler来划分)。请参见：|795033|http://www.martinfowler.com/eaaDev/PassiveScreen.html|offset|length|795034|http://www.martinfowler.com/eaaDev/SupervisingPresenter.html|795035|entityMap|0|LINK|mutability|MUTABLE|url|1^0|0|0|0|0|0|0|0|0|1H|0|0|0|1O|1|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|16|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|17|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|18|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|19|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1A|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1B|8|@]|9|@$S|1C|T|1D|1|1E]]|A|$]]|$1|U|3|V|5|6|7|1F|8|@]|9|@$S|1G|T|1H|1|1I]]|A|$]]|$1|W|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]]|X|$Y|$5|Z|10|11|A|$12|R]]|13|$5|Z|10|11|A|$12|V]]]]

The controller is primarily for co-ordination between the view and the model. 

Unfortunately, it sometimes ends up being mingled together with the view - in small apps though this isn't too bad. 

I suggest you put the:

<pre><code>public void actionPerformed(ActionEvent e)
</code></pre>

in the controller. Then your action listener in your view should delegate to the controller.

As for the validation part, you can put it in the view or the controller, I personally think it belongs in the controller.

I would definitely recommend taking a look at Passive View and Supervising Presenter (which is essentially what Model View Presenter is split into - at least by Fowler). See:

<a href="http://www.martinfowler.com/eaaDev/PassiveScreen.html" rel="nofollow noreferrer">http://www.martinfowler.com/eaaDev/PassiveScreen.html</a>

<a href="http://www.martinfowler.com/eaaDev/SupervisingPresenter.html" rel="nofollow noreferrer">http://www.martinfowler.com/eaaDev/SupervisingPresenter.html</a>

blocks|key|795113|text|根据你的问题，我觉得你对模特的角色有点模糊。模型专注于与应用程序相关的数据；如果应用程序有一个数据库，则模型的工作将是与其对话。它还将处理与该数据相关的任何简单逻辑；如果您有一条规则规定，对于所有TABLE.foo+==“Hooray”的情况，都可以使用它！还有TABLE.bar+==+"Huzzah!“然后设置TABLE.field="W00t!"，然后您希望模型来处理它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|795114|控制器是应该处理大量应用程序行为的工具。因此，要回答你的问题：|795115|我是否只调用控制器中的一个方法就将公共空actionPerformed(ActionEvent+e)放在视图中？|blockquote|795116|我会说不。我想说的是，它应该存在于Controller中；视图应该简单地将来自用户界面的数据提供给Controller，并让Controller决定应该调用哪些方法来响应。|795117|如果是的话，是否应该在主计长中进行任何验证等？|795118|您的大部分验证实际上应该由Controller来完成；它应该回答数据是否有效的问题，如果不是，则将适当的错误消息提供给View。在实践中，为了改进用户体验，您可以将一些简单的理智检查合并到视图层中。(我主要考虑的是web环境，您可能希望在用户点击"+submit“时出现错误消息，而不是等待整个submit+->+process+->+load页面周期才告诉他们他们搞砸了。)不过要小心，你不想重复工作，就像你必须要做的那样。在很多环境中(我再一次想到网络)，你必须把来自用户界面的任何数据当作一堆肮脏的谎言，直到你确认它真的是合法的。|795119|如果是这样的话，我如何反馈错误信息回视图--应该再次通过模型，还是控制器应该直接将其发送回View？|795120|您应该设置一些协议，在这些协议中，视图不一定知道接下来会发生什么，直到Controller告诉它。在用户点击按钮后，你会显示什么屏幕？视图可能不知道，而控制器可能也不知道，直到查看它刚刚获得的数据。它可以是“按预期转到另一个屏幕”或“停留在此屏幕上，并显示此错误消息”。|795121|根据我的经验，模型和视图之间的直接通信应该非常非常有限，而且视图不应该直接更改模型的任何数据；这应该是Controller的工作。|795122|如果验证是在视图中完成的，那么我应该在Controller中添加什么？|795123|参见上文；真正的验证应该在Controller中进行。希望到现在为止，您已经对控制器中的内容有了一些了解。:-)|795124|值得注意的是，所有这些都会使边缘变得模糊；就像大多数像软件工程这样复杂的东西一样，判断的调用也会越来越多。只要使用你最好的判断，试着在这个应用程序中保持一致，并尝试将你所学到的课程应用到下一个项目中。|795125|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|12|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|13|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|14|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|15|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|16|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|17|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|18|8|@]|9|@]|A|$]]|$1|S|3|T|5|F|7|19|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1A|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1B|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|Z|$]]

Based on your question, I get the impression that you're a bit hazy on the role of the Model. The Model is fixated on the data associated with the application; if the app has a database, the Model's job will be to talk to it. It will also handle any simple logic associated with that data; if you have a rule that says that for all cases where TABLE.foo == "Hooray!" and TABLE.bar == "Huzzah!" then set TABLE.field="W00t!", then you want the Model to take care of it.

The Controller is what should be handling the bulk of the application's behavior. So to answer your questions:

<blockquote>
 Do I put the public void actionPerformed(ActionEvent e) in the View with just a call to a method in the Controller?
</blockquote>

I'd say no. I'd say that should live in the Controller; the View should simply feed the data coming from the user interface into the Controller, and let the Controller decide which methods ought to be called in response.

<blockquote>
 If so, should any validation etc be done in the Controller?
</blockquote>

The bulk of your validation really ought to be done by the Controller; it should answer the question of whether or not the data is valid, and if it isn't, feed the appropriate error messages to the View. In practice, you may incorporate some simple sanity checks into the View layer for the sake of improving the user experience. (I'm thinking primarily of web environments, where you might want to have an error message pop up the moment the user hits "Submit" rather than wait for the whole submit -> process -> load page cycle before telling them they screwed up.) Just be careful; you don't want to duplicate effort any more than you have to, and in a lot of environments (again, I'm thinking of the web) you often have to treat any data coming from the user interface as a pack of filthy filthy lies until you've confirmed it's actually legitimate.

<blockquote>
 If so, how do I feedback error messages back to the View - should that go through the Model again, or should the Controller just send it straight back to View?
</blockquote>

You should have some protocol set up where the View doesn't necessarily know what happens next until the Controller tells it. What screen do you show them after the user whacks that button? The View might not know, and the Controller might not know either until it looks at the data it just got. It could be "Go to this other screen, as expected" or "Stay on this screen, and display this error message".

In my experience, direct communication between the Model and the View should be very, very limited, and the View should not directly alter any of the Model's data; that should be the Controller's job.

<blockquote>
 If the validation is done in the View, what do I put in the Controller?
</blockquote>

See above; the real validation should be in the Controller. And hopefully you have some idea of what should be put in the Controller by now. :-)

It's worth noting that it can all get a little blurry around the edges; as with most anything as complex as software engineering, judgment calls will abound. Just use your best judgment, try to stay consistent within this app, and try to apply the lessons you learn to the next project.

blocks|key|795158|text|实际上，我从来没有发现控制器概念是一个特别有用的概念。我在代码中使用严格的模型/视图分离，但是没有明确定义的控制器。这似乎是一种不必要的抽象。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|795159|就个人而言，成熟的MVC似乎像工厂的设计模式，因为它很容易导致混乱和过于复杂的设计。别做建筑航天员。|offset|length|795160|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/404210/design-patterns-architecture-astronaut^0|0|18|5|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

Practically speaking, I've never found the controller concept to be a particularly useful one. I use strict model/view separation in my code but there's no clearly-defined controller. It seems to be an unnecessary abstraction.

Personally, full-blown MVC seems like the factory design pattern in that it easily leads to confusing and over-complicated design. Don't be an <a href="https://stackoverflow.com/questions/404210/design-patterns-architecture-astronaut">architecture astronaut</a>.

blocks|key|795170|text|还要注意，每个Swing小部件都可以被认为包含三个MVC组件:每个组件都有一个模型(即ButtonModel)、一个视图(BasicButtonUI)和一个控件(JButton本身)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|795171|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

also note that each Swing widget is can be considered to contain the three MVC components: each has a Model (ie ButtonModel), a View (BasicButtonUI), and a Control (JButton itself).

blocks|key|795205|text|下面是我使用的经验法则:如果这是我将专门用于此页面上的操作的过程，则它属于控制器，而不是模型。模型应该只为数据存储提供一个连贯的抽象。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|795206|我是在使用开发人员编写的一个大型的、由开发人员编写的、认为自己理解MVC但实际上并不理解的were应用程序之后提出这一建议的。他们的“控制器”被简化为八行调用静态类方法的行，这些方法通常在其他地方调用://使他们的模型仅限于创建命名空间的方式。适当地重构它可以完成三件事:将所有SQL转换到数据访问层(又名模型)，使控制器代码更冗长，但更容易理解，并将旧的“模型”文件减少为零。:-)|795207|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Here is a rule of thumb that I use: if it is a procedure that I will be using specifically for an action on this page, it belongs in the controller, not the model. The model should provide only a coherent abstraction to the data storage.

I've come up with this after working with a large-ish webapp written by developers who thought they were understood MVC but really didn't. Their "controllers" are reduced to eight lines of calling static class methods that are usuall called nowhere else :-/ making their models little more than ways of creating namespaces. Refactoring this properly does three things: shifts all the SQL into the data access layer (aka model), makes the controller code a bit more verbose but a lot more understandable, and reduces the old "model" files to nothing. :-)

blocks|key|2319685|text|你在控制器中放的内容基本上是正确的。这是模型与视图交互的唯一方式。执行的操作可以放在View中，但是实际的功能可以放在另一个类中，它可以充当Controller。如果要这样做，我建议查看命令模式，这是一种抽象具有相同接收器的所有命令的方法。抱歉，我错了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2319686|无论如何，适当的MVC实现将只具有以下交互:模型->视图视图->控制器控制器->视图|2319687|唯一可能有另一个交互的地方是，如果您使用一个观察者来更新视图，那么视图需要向Controller询问它需要的信息。|2319688|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

You are essentially right about what you put in the controller. It is the only way the Model should interact with the View. The actionperformed can be placed in the View, but the actual functionality can be placed in another class which would act as the Controller. If you're going to do this, I recommend looking into the Command pattern, which is a way of abstracting all of the commands that have the same receiver. Sorry for the digression.

Anyway, a proper MVC implementation will have the following interactions only:
Model -> View
View -> Controller
Controller -> View

The only place where there may be another interaction is if you use an observer to update the View, then the View will need to ask the Controller for the information it needs.

blocks|key|795273|text|控制器实际上是视图的一部分。它的工作是找出满足请求所需的服务，将视图中的值解封为服务接口所需的对象，确定下一个视图，并将响应编组到下一个视图可以使用的表单中。它还处理引发的任何异常，并将它们呈现为用户可以理解的视图。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|795274|服务层是知道用例、工作单元和模型对象的东西。对于每种视图，控制器将是不同的--对于桌面、基于浏览器的、Flex或移动UI，您将没有相同的控制器。所以我说它确实是UI的一部分。|795275|面向服务的:工作就是在那里完成的。|795276|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Controller is really part of the View. Its job is to figure out which service(s) are needed to fulfill the request, unmarshal values from the View into objects that the service interface requires, determine the next View, and marshal the response back into a form that the next View can use. It also handles any exceptions that are thrown and renders them into Views that users can understand.

The service layer is the thing that knows the use cases, units of work, and model objects. The controller will be different for each type of view - you won't have the same controller for desktop, browser-based, Flex, or mobile UIs. So I say it's really part of the UI. 

Service-oriented: that's where the work is done.

blocks|key|928975|text|MVC的问题在于人们认为视图、控制器和模型必须尽可能相互独立。他们并不认为它是M(VC)+(视图和控制器经常相互交织在一起)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|928976|控制器是用户界面的输入机制，在视图中经常被混在一起，特别是在GUI中。然而，视图是输出的，控制器是输入的。视图通常在没有相应控制器的情况下工作，但是如果没有视图，控制器的用处通常要小得多。用户友好的控制器使用视图以更有意义、更直观的方式解释用户的输入。这就是为什么它很难将控制器的概念与视图分开。|928977|假设一个无线电控制的机器人在一个密封的盒子里的探测场上作为模型。|928978|模型都是关于状态和状态转换的，没有输出(显示)的概念，也没有触发状态转换的内容。我可以得到机器人在场地上的位置，机器人知道如何转换位置(向前/后退/左/右)。很容易想象没有视图或控制器，但没有任何用处。|928979|想象一下没有控制器的视图，例如，网络上另一个房间中的某个人在另一个房间中观察机器人位置为(x，y)坐标沿着滚动控制台流下。这个视图只是显示模型的状态，但是这个家伙没有控制器。同样，在没有控制器的情况下，很容易想象到这个视图。|928980|想一想一个没有视野的控制器，例如，有人被锁在衣橱里，无线电控制器与机器人的频率相调。该控制器发送输入并导致状态转换，而不知道它们对模型做了什么(如果有的话)。很容易想象，但如果没有来自视图的某种反馈，就无法真正发挥作用。|928981|大多数用户友好的UI与控制器协调视图，以提供更直观的用户界面。例如，想象一个带有触摸屏的视图/控制器，显示机器人在二维中的当前位置，并允许用户触摸屏幕上恰好位于机器人前面的点。控制器需要有关视图的详细信息，例如视口的位置和比例，以及相对于屏幕上机器人的像素位置所触及的点的像素位置)才能正确地解释这一点(不像用无线电控制器锁在衣柜里的人)。|928982|我回答了你的问题了吗？|928983|控制器是从用户那里获取用于导致模型过渡状态的输入的任何东西。尽量保持视图和控制器之间的分离，但要意识到它们之间往往是相互依赖的，所以如果它们之间的边界是模糊的，那么视图和控制器作为单独的包可能不会像您所希望的那样被清晰地分开，但这是可以的。您可能必须接受控制器不会与视图清晰地分离，就像视图与模型一样。|928984|..。是否应在主计长中进行任何验证等？如果是这样的话，我如何反馈错误信息回视图--应该再次通过模型，还是控制器应该直接将其发送回View？
如果验证是在视图中完成的，那么我应该在Controller中添加什么？|blockquote|928985|我认为，一个链接的视图和控制器应该自由地交互，而不需要经过模型。控制器接受用户的输入并进行验证(可能使用来自模型和/或视图的信息)，但是如果验证失败，控制器应该能够直接更新其相关视图(例如错误消息)。|928986|这方面的严峻考验是问自己，一个独立的视角(即另一个房间里的人通过网络观察机器人的位置)是否应该因为别人的验证错误而看到任何东西(例如，壁橱里的那个人试图告诉机器人离开战场)。通常情况下，答案是否定的-验证错误阻止了状态转换。如果没有状态转换(机器人没有移动)，就没有必要告诉其他观点。壁橱里的人没有得到任何反馈，说他试图导致非法的过渡(没有视图-糟糕的用户界面)，其他人也不需要知道这一点。|928987|如果那个拿着触摸屏的家伙想把机器人送出战场，他收到了一条用户友好的信息，要求他不要把机器人从探测场上发送出去，这样他就不会杀死机器人，但是，其他人也不需要知道这一点。|928988|如果其他视图确实需要知道这些错误，那么您实际上是说来自用户的输入和任何由此产生的错误都是模型的一部分，整个过程稍微复杂一些.|928989|entityMap^0|0|3|13|5|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@$9|19|A|1A|B|C]|$9|1B|A|1C|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1D|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|1E|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|1F|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|1G|8|@]|D|@]|E|$]]|$1|N|3|O|5|6|7|1H|8|@]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1I|8|@]|D|@]|E|$]]|$1|R|3|S|5|6|7|1J|8|@]|D|@]|E|$]]|$1|T|3|U|5|6|7|1K|8|@]|D|@]|E|$]]|$1|V|3|W|5|X|7|1L|8|@]|D|@]|E|$]]|$1|Y|3|Z|5|6|7|1M|8|@]|D|@]|E|$]]|$1|10|3|11|5|6|7|1N|8|@]|D|@]|E|$]]|$1|12|3|13|5|6|7|1O|8|@]|D|@]|E|$]]|$1|14|3|15|5|6|7|1P|8|@]|D|@]|E|$]]|$1|16|3|-4|5|6|7|1Q|8|@]|D|@]|E|$]]]|17|$]]

The problem with <code>MVC</code> is that people think the view, the controller, and the model have to be as independent as possible from each other. They do not - a view and controller are often intertwined - think of it as <code>M(VC)</code>.

The controller is the input mechanism of the user interface, which is often tangled up in the view, particularly with GUIs. Nevertheless, view is output and controller is input. A view can often work without a corresponding controller, but a controller is usually far less useful without a view. User-friendly controllers use the view to interpret the user's input in a more meaningful, intuitive fashion. This is what it makes it hard separate the controller concept from the view. 

Think of an radio-controlled robot on a detection field in a sealed box as the model.

The model is all about state and state transitions with no concept of output (display) or what is triggering the state transitions. I can get the robot's position on the field and the robot knows how to transition position (take a step forward/back/left/right. Easy to envision without a view or a controller, but does nothing useful

Think of a view without a controller, e.g. someone in a another room on the network in another room watching the robot position as (x,y) coordinates streaming down a scrolling console. This view is just displaying the state of the model, but this guy has no controller. Again, easy to envision this view without a controller.

Think of a controller without a view, e.g. someone locked in a closet with the radio controller tuned to the robot's frequency. This controller is sending input and causing state transitions with no idea of what they are doing to the model (if anything). Easy to envision, but not really useful without some sort of feedback from the view.

Most user-friendly UI's coordinate the view with the controller to provide a more intuitive user interface. For example, imagine a view/controller with a touch-screen showing the robot's current position in 2-D and allows the user to touch the point on the screen that just happens to be in front of the robot. The controller needs details about the view, e.g. the position and scale of the viewport, and the pixel position of the spot touched relative to the pixel position of the robot on the screen) to interpret this correctly (unlike the guy locked in the closet with the radio controller).

Have I answered your question yet? :-)

The controller is anything that takes input from the user that is used to cause the model to transition state. Try to keep the view and controller a separated, but realize they are often interdependent on each other, so it is okay if the boundary between them is fuzzy, i.e. having the view and controller as separate packages may not be as cleanly separated as you would like, but that is okay. You may have to accept the controller won't be cleanly separated from the view as the view is from the model.

<blockquote>
 ... should any validation etc be
 done in the Controller? If so, how do
 I feedback error messages back to the
 View - should that go through the
 Model again, or should the Controller
 just send it straight back to View?
 
 If the validation is done in the View,
 what do I put in the Controller?
</blockquote>

I say a linked view and controller should interact freely without going through the model. The controller take the user's input and should do the validation (perhaps using information from the model and/or the view), but if validation fails, the controller should be able to update its related view directly (e.g. error message).

The acid test for this is to ask yourself is whether an independent view (i.e. the guy in the other room watching the robot position via the network) should see anything or not as a result of someone else's validation error (e.g. the guy in the closet tried to tell the robot to step off the field). Generally, the answer is no - the validation error prevented the state transition. If there was no state tranistion (the robot did not move), there is no need to tell the other views. The guy in the closet just didn't get any feedback that he tried to cause an illegal transition (no view - bad user interface), and no one else needs to know that.

If the guy with the touchscreen tried to send the robot off the field, he got a nice user friendly message asking that he not kill the robot by sending it off the detection field, but again, no one else needs to know this.

If other views do need to know about these errors, then you are effectively saying that the inputs from the user and any resulting errors are part of the model and the whole thing is a little more complicated ...

blocks|key|2319784|text|我们这样做，主要是使用控制器来处理和响应用户驱动的输入/操作(除了视图、数据和明显的_Logic内容之外，其他所有东西都是_Model+)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2319785|(1)+(响应、反应-+webapp对用户“做”什么)+Blog_Controller|2319786|->main()|2319787|->handleSubmit_AddNewCustomer()|2319788|->verifyUser_HasProperAuth()|2319789|(2)+(“业务”逻辑，webapp“思考”的内容和方式)+Blog_Logic|2319790|->sanityCheck_AddNewCustomer()|2319791|->handleUsernameChange()|2319792|->sendEmail_NotifyRequestedUpdate()|2319793|(3)+(视图、门户、webapp如何“显示”)+Blog_View|2319794|->genWelcome()|2319795|->genForm_AddNewBlogEntry()|2319796|->genPage_DataEntryForm()|2319797|(仅在每个博客*类的_construct()中获取数据对象，用于将所有webapp/内存中的数据作为一个对象保存在一起)+Blog_Meta|2319798|(5)+(基本数据层，对DBs的读写)+Blog_Model|2319799|->saveDataToMemcache()|2319800|->saveDataToMongo()|2319801|->saveDataToSql()|2319802|->loadData()|2319803|有时，我们会对在C或L中放置一个方法感到有点困惑，但是模型是坚如磐石的，清晰的，而且由于内存中的所有数据都驻留在_Meta中，所以它也是一个不需要思考的方法。顺便说一句，我们最大的飞跃是采用了_Meta使用，因为它清除了各种_C、_L和_Model对象中的所有crud，使其在精神上易于管理，而且，在一次突然之间，它给了我们所谓的“依赖注入”，或者一种传递整个环境以及所有数据的方法(这些数据的好处是很容易创建“测试”环境)。|2319804|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1G|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1H|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1I|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1J|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1K|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1L|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1M|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1N|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1O|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1P|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1R|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1S|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|1T|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|1U|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|1V|8|@]|9|@]|A|$]]|$1|17|3|18|5|6|7|1W|8|@]|9|@]|A|$]]|$1|19|3|1A|5|6|7|1X|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|1D|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]]|1E|$]]

We do it thusly, using Controllers mainly to handle and react to user-driven input/actions (and _Logic for everything else, except view, data and obvious _Model stuff):

(1) (response, reaction - what the webapp "does" in response to user)
Blog_Controller

->main()

->handleSubmit_AddNewCustomer()

->verifyUser_HasProperAuth()

(2) ("business" logic, what and how the webapp "thinks")
Blog_Logic

->sanityCheck_AddNewCustomer()

->handleUsernameChange()

->sendEmail_NotifyRequestedUpdate()

(3) (views, portals, how the webapp "appears")
Blog_View

->genWelcome()

->genForm_AddNewBlogEntry()

->genPage_DataEntryForm()

(4) (data object only, acquired in _construct() of each Blog* class, used to keep all webapp/inmemory data together as one object)
Blog_Meta

(5) (basic data layer, reads/writes to DBs)
Blog_Model

->saveDataToMemcache()

->saveDataToMongo()

->saveDataToSql()

->loadData()

Sometimes we get a little confused on where to put a method, in the C or the L. But the Model is rock solid, crystal clear, and since all in-memory data resides in the _Meta, it's a no-brainer there, too. Our biggest leap forward was adopting the _Meta use, by the way, as this cleared out all the crud from the various _C, _L and _Model objects, made it all mentally easy to manage, plus, in one swoop, it gave us what's being called "Dependency Injection", or a way to pass around an entire environment along with all data (whose bonus is easy creation of "test" environment).

I think I understand the basic concepts of MVC - the Model contains the data and behaviour of the application, the View is responsible for displaying it to the user and the Controller deals with user input. What I'm uncertain about is exactly what goes in the Controller.

Lets say for example I have a fairly simple application (I'm specifically thinking Java, but I suppose the same principles apply elsewhere). I organise my code into 3 packages called <code>app.model</code>, <code>app.view</code> and <code>app.controller</code>.

Within the <code>app.model</code> package, I have a few classes that reflect the actual behaviour of the application. These <code>extends Observable</code> and use <code>setChanged()</code> and <code>notifyObservers()</code> to trigger the views to update when appropriate.

The <code>app.view</code> package has a class (or several classes for different types of display) that uses <code>javax.swing</code> components to handle the display. Some of these components need to feed back into the Model. If I understand correctly, the View shouldn't have anything to do with the feedback - that should be dealt with by the Controller.

So what do I actually put in the Controller? Do I put the <code>public void actionPerformed(ActionEvent e)</code> in the View with just a call to a method in the Controller? If so, should any validation etc be done in the Controller? If so, how do I feedback error messages back to the View - should that go through the Model again, or should the Controller just send it straight back to View?

If the validation is done in the View, what do I put in the Controller?

Sorry for the long question, I just wanted to document my understanding of the process and hopefully someone can clarify this issue for me!

What goes into the "Controller" in "MVC"?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我想我理解MVC的基本概念--模型包含应用程序的数据和行为，视图负责向用户显示它，Controller处理用户输入。我不确定的是控制器到底是怎么回事。例如，假设我有一个相当简单的应用程序(我专门考虑Java，但我认为同样的原则也适用于其他地方)。我将我的代码组织成3个包，名为app.model、app.view和app...

问什么是"MVC“中的”控制器“？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么是"MVC“中的”控制器“？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么是"MVC“中的”控制器“？
EN