需要帮助理解 MVC 设计模式
我试图在java中找到MVC设计模式的一个很好的例子。
这是我从阅读中了解到的，如果我错了，请纠正我：
我有模型部分，它是程序背后的逻辑，假设我们有电话簿，那么从数组中添加和删除联系人将是模型。
Gui 是视图，它包含按钮，单击这些按钮后，模型就会发生变化。
我想了解什么是控制器部分，是 ActionListeners 吗？如何在实践中分离这些模块。
谢谢
I am trying to find a ood example of MVC design pattern in java.
This is what i understood from reading about it, please correct me if I am wrong:
I have the Model part which is the logic behind the program, let's say if we have a phonebook, so adding and removing contact from the Array will be the model.
The Gui is the view and it contains buttons that upon clicking them, the model is changing.
What I am trying to undersand what is the controller part, is it the ActionListeners? how to you seperate those modules in practice.
thank you
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我已经使用 MVC 很长时间了，发现它是一种实现软件设计的绝佳机制。当你学习它时，我的建议是首先让一切成为控制器。换句话说，创建一个类，该类具有包含状态（模型）的成员以及显示和操作该状态（视图）的成员。让类的函数从视图中获取输入，修改数据，然后更新视图（控制器）。
这显然没有体现设计模式想要的分离，但它将帮助您快速学习识别什么是清晰的视图组件和什么是清晰的模型组件。然后花一些时间将独立的模型对象（这是最简单的）和稍后的独立视图对象分离成单独的文件/对象。
在您对一两个项目执行此操作后，分离将开始变得更加自然和明显，当您开始新项目时，您会在开始编写代码（设计阶段）之前知道哪些事情去哪里。
根据个人经验，我认为如果您首先在没有真正的开发经验的情况下尝试对所有内容进行分类，您更容易思考过度并做太多工作。你会发现，如果你花一些时间以自然的方式编写一个项目，然后在你写的过程中或事后分解它，它会更有意义。
I've used MVC for a long time and find it to be a fantastic mechanism for approaching software design. My advice while you're learning it is to make everything a controller at first. In other words, create a class that has members that contain state (model) and also members that display and manipulate that state (views). Make the functions of your class take input from the views, modify the data, and then update the views (controller).
This obviously doesn't embody the separation that the design pattern intends, but it will help you learn quickly to identify what is a clear view component and what is a clear model component. Then take some time to separate out into separate files/objects independent model objects (which is easiest) and later independent view objects.
After you do this for a project or two, the separation will begin to be more natural and obvious and as you start new projects you'll know before you start writing code (design phase) what sorts of things go where.
From personal experience I think you're more apt to overthink things and do too much work if you try to categorize everything without some real development experience first. You'll find if you spend some time writing a project in a natural way and then breaking things down as you go or afterwords that it will make more sense.
控制器通常是 MVC 中人们最难以定义的部分。在您的示例中，它是加载和操作电话簿的位，以及选择要使用哪个视图的位。
The controller is usually the part of MVC that people have the most trouble defining. In your example, it's the bit that loads and manipulates the phonebook, as well as the bit that selects which view to use.
在你的例子中，两者似乎是一致的。
但是，以以下场景为例。
全厂范围内的内部联系簿。
在这种情况下（我们假设），大多数用户无法将联系人添加到地址簿。
只有人力资源部门才能将新联系人 (=员工) 添加到列表中。
我们现在有 3 段真正独立的代码：
这是一个简单的列表，始终显示员工/邮件地址的完整列表。
查看员工完全无法控制列表 - 他/她只是查看它。
员工可以更改列表的外观（例如按姓氏排序、更改字体）。
任何此类更改都是查看者内部的，并且不由模型或控制器记录或监督。
这可以是另一个 GUI，但能够更改列表状态（例如添加/删除员工）。
如果您想将其发挥到极致，请假设它是一个类似贝壳的窗口。
当人力资源员工希望添加新员工时，他/她在 shell 中输入：
“添加‘john smith’johns2@internalMail”
这正如你所描述的。它执行流程中必要的逻辑。
例如，它不会添加已经添加的员工等等。
您的场景的“问题”是，它可能不是 MVC 的经典场景。
MVC意味着反对称。也就是说，并非所有“观众”都是相似的，有些是“特殊”/管理员，并且比“普通”观众有额外的好处。
希望它能澄清事情。
In your example, the two seem to converge.
However, take for example the following scenario.
A factory-wide internal contact book.
In this scenario (let's assume that), most users can't add contacts to the address book.
Only the Human-Resource department can add a new contact (=employee) to the list.
We now have 3 truly separate pieces of code:
This is a simple list, that always presents the whole list of employees/mail-addresses.
The viewing employee, has absolutely no control over the list - he/she just views it.
The employee could change the appearance of the list (e.g. sort it by last name, change font).
Any such change is internal to the viewer, and is not recorded or supervised by the model or controller.
This can be another GUI, but with the ability to make changes to the list state (e.g. add/remove employees).
If you wish to take this to the extreme, assume it's a shell-like window.
When an HR employee wishes to add a new employee, he/she types into the shell:
"ADD 'john smith' johns2@internalMail"
This is as you described. It performs the necessary logic of the process.
For example, it won't add an employee that was already added and so on.
The "problem" with your scenario, is that it's probably not a classic one for MVC.
MVC implies anti-symmetry. That is, NOT all "viewers" are alike, some are "special"/admin and have additional benefits over "regular" viewers.
Hope it clears things.