我最近了解了MVC设计模式。我正在从“头第一设计模式书”中学习。
根据这本书(如果我正确理解的话):
模型是大多数应用程序逻辑和数据。
视图基本上是向用户表示模型的GUI。
控制器负责“调解”,并充当视图和模型之间的“中间人”。View向Controller报告用户进行了操作,Controller将其转换为对模型的方法调用。下图显示了上面描述的情况:
然而,
哪一个是真的还是更常见?用户是直接与控制器交互,还是直接与视图交互?这两种方法都可以接受吗?哪一种更常见?
发布于 2014-03-29 00:50:18
用户与视图交互,但视图必须将操作传递给Controller。Controller可以更新模型,但并不是每个/任何更改都需要它。
我所提供的描述是基于我对MVC的.NET实现的个人经验。您的实现可能会有所不同。
Controller是处理操作的地方,基本上是一个业务层。一个简单的控制器只会将模型中的数据输入到视图中。复杂的Controller将执行各种操作,直至安全管理、身份验证、授权、注册以及许多其他事情。
视图只应负责以用户能够理解的方式显示信息。在这里可以与Controller和Model交叉,因为诸如单页应用程序(SPAs)这样的东西将为用户提供数据验证反馈。任何其他的交叉都是严重的皱眉。
该模型处理数据。这包括数据的验证(如适用)。数据存储和检索也在这一层进行。
似乎围绕着谁在什么时候做什么有一些困惑。我包含了两种不同的MVC架构概述,因为它们是相似的,但不是相同的。这两种解释都有余地。可能还有更多。上面的描述是我从多个来源对MVC的解释,包括我自己使用这种方法构建应用程序的经验。希望这一更新将有助于消除一些混乱。
MVC是一种为软件开发构建分离关注点设计模式的尝试。据我所知,它主要是在基于web的应用程序中实现的。
视图处理所有用户交互。如果用户单击按钮,则视图将确定单击是用户界面交互还是超出其关注范围的内容(控制器交互)。如果按钮执行类似于将值从一个字段复制到另一个字段的操作,则您的实现将确定它是视图关注点还是Controller关注点。在处理单个页面应用程序(SPA)时,您很可能只会有这种模糊的关注点。
控制器是处理操作的地方。视图已通知用户,决定更改某些字段的值。控制器可以对该数据执行验证,也可以由模型处理。同样,这是依赖于实现的。如果Controller具有安全特性,它可能会确定用户没有执行该操作的足够权限。它将拒绝更改并相应地更新视图。Controller还确定要从模型检索哪些数据,如何打包数据,并使用该数据更新视图。
该模型决定如何和在何处存储数据。它还可以在存储数据之前对数据执行验证(它应该这样做,因为人们有时会绕过View )。
维基百科有一篇关于MVC的文章。
微软MVC概述。
发布于 2014-03-29 09:21:16
用户与控制器交互。从技术角度来看,您不是在与视图交互,而是使用它与Controller交互。
从表面上看,用户似乎是在与GUI交互--对非程序员来说也是如此--这更有意义,但是单击一个按钮,您基本上是在和Controller而不是View交谈。
而且并不是所有的应用程序--即使是MVC web应用程序--都有一个GUI。您可以通过API与Controller交互--例如,放置在Controller本身中的简单url-routes
。
控制器应该是接收和处理用户请求的地方。所以,如果你以某种方式直接从视图访问模型
发布于 2014-03-29 18:26:25
让我们用一个具体的例子来说明为什么用户直接与视图而不是控制器交互。
在iPhone上的音乐应用程序中,一个高级功能是播放播放列表。“播放播放列表”是应用程序控制器的一个功能。
激活该功能的方法不止一种。我可以点击应用程序内的播放列表,也可以要求Siri (语音接口)执行同样的功能。这是两种不同的姿态,被不同的观点所认可。
每个视图中的反馈也不同。Siri会告诉你它在播放你要求的音乐。这款音乐应用程序将向你展示它正在播放播放列表的视觉反馈。
https://softwareengineering.stackexchange.com/questions/234116
复制相似问题