我有一个使用MVC作为模式在java中创建游戏的任务。问题是我读到的关于MVC的内容并不是老师告诉我的。
我读到的是模型是信息对象，它们由控制器操纵。因此，在游戏中，控制器会改变对象的位置并检查是否存在任何碰撞等。
我的老师告诉我的是，我应该在模型中放置通用的所有内容，控制器应该只告诉模型给出了哪个输入。这意味着游戏循环将在模型类中，但也包括碰撞检查等。所以我从他的故事中得到的是View是屏幕，Controller是unput handeler，而Model是剩下的。
有人能指出我正确的方向吗？
答案 0 :(得分：5)
实际上，给定应用程序的MVC模式有多个有效实现。 作为MVC应用程序的应用程序的根本特征在于，开发人员将功能分为三大类模型，视图和控制器。
在大多数情况下，模型包含应用程序当前状态和/或底层数据的抽象。视图包含处理演示的所有内容。控制器通常是视图和模型之间的中间实例，反之亦然：例如如果用户输入修改了数据模型，则控制器应该应用这些更改（如果它们无效，则应该使它们无效）;反之亦然，如果模型中存在一个状态，该状态被定义为导致视图的某个输出，则控制器将强制执行此操作。
然而，这些是模糊的线条。 MVC设计的适用性通常受到您使用的编程语言的限制。
换句话说，你必须在某种程度上即兴发挥。单独的功能尽可能合理，但在没有意义的情况下不要过分。
一些资源：
答案 1 :(得分：0)
您正在描述MVP模式：您不希望模型与视图相关，因此您的视图（屏幕）无法直接访问您的模型。大多数情况下，它会产生更干净的代码，但这取决于您的使用情况：http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter
在MVC中，您可以在视图中访问模型，因此您可以创建与视图更紧密耦合的模型对象（例如，参见数据绑定）（也有一些优点）。
将大多数逻辑放在模型中而不是控制器中直接与MVC或MVP无关，它是关于域驱动设计的，它是OOP的重要组成部分：http://en.wikipedia.org/wiki/Domain-driven_design
这是OOP的最佳实践，如果您的域对象（模型）可以回答有关其包含的数据的问题，那么它必须包含实现，不要通过Anemic Domain Model（今天非常流行，因为功能编程的炒作）：http://www.martinfowler.com/bliki/AnemicDomainModel.html