首页 文章

MVC系统如何工作？

提问于
浏览 次
20

我正在尝试学习MVC模式，但每个地方都说不同的东西 . 所以现在我不知道真正的MVC是什么 .

所以我猜它是最纯粹的MVC：

  • Model 是 just data 并通知数据更改 .

  • View 读取 Model 的消息以更新视图 .

  • Controller 从 View 读取用户输入并更改模型 .

Implementing

  • Model 不认识任何人 .

  • View 知道 Model .

  • Controller 知道 View 和 Model .

伪代码：

/* Model */
class Color{ 
  color = blue;
  setColor(color);
  notifyUpdate();
}
/* View */
class ColorPicker(model){
  model.register(update);
  update(){
    this.colorToExhibit = model.color;
  }
}
/* Controller */
class Colorize(view, model){
  view.register(update);
  update(color){
    model.setColor(color);
  }
}

一些问题：

  • 是吗？

  • 我看不出为什么 View 不能直接改变 Model ，而是通过Controller .

  • 假设我有动作后要执行的动画 . 谁必须处理这个动画：模型，视图或控制器？另外：动画逻辑是模型，视图或控制器的一部分？更多：假设一个扑克游戏 . 在用户选择动作（例如，'Raise'）之后，系统必须播放动画（例如，筹码从玩家点到桌面） . 我如何看待这个扑克示例（带动画）作为MVC？你能解释并给出一个伪代码吗？

谢谢 .

model-view-controller oop design-patterns

3 回答

  • 18

    模型只是数据并通知数据变化 . View读取模型的消息以更新视图 . 控制器从View中读取用户输入并根据更改模型 .

    模型不仅仅是数据 . 该模型也是业务逻辑 . 它包含系统的所有智能，或者至少是幕后智能的抽象（例如数据库调用或其他服务调用） . 考虑一下这样的说法，“让模型保持沉重，控制器变亮” .

    模特不认识任何人 . View知道模型 . Controller知道View和Model .

    模型不认识任何人，它是正确的 . 模型应该在应用程序之间可移植，不应以任何方式依赖于UI问题 . （在这种情况下，视图和控制器是UI问题 . ）

    View知道模型，也是正确的 . 视图基本上“绑定”到模型 . 它呈现了所有UI元素，并相应地将UI数据放置在UI元素中 .

    Controller类型"knows the View."它知道它应该直接控制哪个View，但它对该视图一无所知 . 它也不知道哪个视图来自哪个控件 . Controller响应事件 . 从UI进入事件，携带某种状态信息（可能是ViewModel），通过模型（业务逻辑发生的地方）引导逻辑控制，并使用模型（或ViewModel，如果形状）进行响应特定视图的特定数据与模型和视图不同 .

    我不明白为什么View不能直接改变Model，而是通过Controller .

    View可以在用户交互的上下文中操作Model，但不应期望这些更改以任何方式持续存在 . View应被视为“客户端”，并且不知道“服务器端” . （即使您正在谈论的是本机应用程序而不是Web应用程序 . ）保持任何更改都被视为UI“操作”或“事件”，并且会转到Controller以实现它 .

    假设我有动作后要执行的动画 . 谁必须处理这个动画：模型，视图或控制器？另外：动画逻辑是模型，视图或控制器的一部分？

    动画听起来像是完全基于UI的操作 . 它将在视图内 . 除了UI动画之外还有更多的事情发生吗？动画是否会改变后端的任何内容？例如，如果我有一个Web应用程序，并且当页面加载时，我想淡入一些数据（一个动画）......从模型或控制器的角度来看，这样做是做任何事情的 .

    假设一个扑克游戏 . 在用户选择动作（例如，'提升'）之后，系统必须播放动画（例如，从玩家地点到桌面的筹码） . 我如何看待这个扑克示例（带动画）作为MVC？你能解释并给出一个伪代码吗？

    动作（“提升”）是一个控制器事件 . UI将联系控制器以执行“加注” . 所以Controller可能有这样的方法：

    View Raise(GameState state)
{
    // Interact with the Models to update the known state of the game.
    // The Models would perform the actual Poker game logic.
    // Respond with a View bound to updated Models.
}

    一旦Controller使用新视图响应UI，该视图将包含要显示给用户的任何动画 . （毕竟，除非操作成功，否则您不想执行动画，对吗？当Controller响应时使用新视图指示成功操作的UI，然后动画将播放 . 它可能会使用一个指示错误的视图来响应UI，在这种情况下，View会显示其他内容 . ）

    回复于
  • 25

    我将使用简单的Bank类比 .

    • Tellers是视图 .

    • 跑步者是控制者 .

    • 银行家是模特 .

    银行家是聪明人，他们了解所有的业务逻辑并完成所有复杂的计算 .

    跑步者用于将资金（数据）从银行家转移到Tellers .

    出纳员向客户提供资金 .

    一个简单的表示：

    Model

    public class BankAccount
{
     public int ID;
     public int Balance;

     public BankAccount(int id)
     {
         ID = id;
         Balance = DetermineAmount();
     }

     public int DetermineAmount()
     {
         // Gather transaction info, debits, credits and return a
         // sum of the amount left in the account depending on the
         // id provided.
     }
}

    Controller

    public class BankAccountController
    {

         public ViewResult Index(int id)
         {
             BankAccount account = new BankAccount(id);
             return View(account);
         }

    }

    View

    <ul id="account-info">
   <li>Account ID: `@Model.ID`</li>    
   <li>Balance: `@Model.Balance`</li>
</ul>
    回复于
  • 8

    如果您对历史真实的MVC感兴趣，请从Trygve Reenskaug开始 . 他在20世纪70年代后期创作（观察？，编目??） . 首先，请阅读1979年的"Models-Views-Controllers" . 它定义了术语 . 仔细注意它的 Headers - all three roles are pluralized . 这是大多数人似乎首先出错的第一件事 .

    我发现最初使用MVC的最佳描述实际上是在2004年的题为"Inside Smalltalk MVC"的演示文稿中 . 我猜想那些描述Smalltalk 80最终版MVC的规范论文是Krasner＆Pope的"A Cookbook for Using the Model-View-Controller User Interface Paradigm in the Smalltalk-80"和Steve Burbeck的"Applications Programming in Smalltalk-80: How to use Model-View-Controller (MVC)" . 两篇论文都值得一读 .

    如果你有时间去杀人并且不介意听罗伯特·马丁，他就做了一个很好的keynote at Ruby Midwest 2011，触及了MVC . 这是一个多小时，但非常有趣和启发 . 我倾向于认为大多数实现都会使MVC出错 . 我花了一点时间环顾四周，最后找到了一个我可以链接到哪个图表来描述MVC . 我喜欢的那个来自教皇和克拉斯纳 .

    MVC http://www.as3dp.com/wp-content/uploads/2010/02/mvc_pope_krasner.png

    从我的观点来看，以下是关键点：

    • a model instance is responsible for notifying the interested objects of changes . 请注意，这些可以是任何对象实例 . 该图显示了视图和控制器在此处接收更新 .

    • views are responsible for querying the current state and displaying the results . 它们通常也执行过滤或数据转换 .

    • controllers are responsible for accepting user input and forwarding view messages 沿着视图 .

    • 查看消息是MVC中的常见主题 . 重要的是，它们独立于UI世界 - 这些不是鼠标点击，而是视频特定的事件语言 . 这将我们带到下一点 .

    • The view does not depend on the controller in any way . Controller负责安排和创建视图，并提供世界其他地方和视图之间的界面 .

    • 在一个完美的世界里， the view is responsible for making the model representation visible . 这是MVC应用于桌面应用程序时的工作方式 .

    现实情况是，MVC已被扭曲并重写为网络世界 . 它是一个替代方案的主题演讲，它更适合Web应用程序 - 他称之为Interactor，Entity，Boundary Architecture缺乏更好的名称 . 挖掘与他关于"the Lost Years of Architecture"的谈话有关的事情 .

    回复于

相关问题