如何理解Web应用程序的MVC模型?

在架构一个运用时,我们要树立模型,说得土一点就是建表,然后设定对这些表的各种能够操作。比如建一个 students 表,允许关联班级、导师,然后定义增删改查的操作,别搞出破绽或许脏数据……这些事情完成,我们就完成了“范围模型”或许说“业务逻辑”(domain logic/business logic)。

但我们没有方法依据“需求”直接架构这些 Model。需求是多变的,甚至是理性的、碎片化的。而“Model”需务实打实地对应一个面向对象编程意义上的“对象”,追求单一性、里氏可交流、接口分别、开闭准绳……一堆准绳。

在理想中,我们不能够对“需求”运用“单一性”准绳。用户翻开一个知乎用户页就想看到他赞过的帖子他宣布的回答;翻开一篇网易旧事就想看脑残评论;翻开一本文艺作品就想倾听习总在文艺座谈会上的讲话……假设把各种需求都塞到模型里,会发生少量冗余和重复的代码。

此外,对象之间自然不擅长走“任务流”,所以触及“提交了 A 然后进入 B 页面”这种运用层面的流程需求,也很难用 Model 对象表达。

何况,需求之间也是存在“承袭”的,比如一个网站的一大波页面都需求展现用户的登录信息和头像。这种数据假设你不想在 V 外面直接读 Model 的话,就只要靠 C 之间的承袭来传递了。

假设一个运用同时有网站、移动 APP 和 API 接口就更容易了解了,Model 在不同运用之间应当是可以复用的,由于它走的是“业务逻辑”。

所以,我们无妨把 C 了解为“用户需求的一种笼统”。除了担任倾听用户,还担任给用户一切他需求的数据(这有些接近 ViewModel 的概念了)。这局部东西,其实也被称为“运用逻辑”(application logic)。

假设运用是个 RESTFul 的 API,那能够简直没有 C,由于它的“用户”十分“理性”(同理,题主的例子需求是既复杂又单一的“查库”,够理性,C 也没啥用)。但关于 RSS,C 能够又是必要的,但依然简直没有 V。关于报表运用, CMS,SNS,管理后台……不同形状的运用,MVC 的状况会是天差地别。

另外:

虽然题主觉得“对 V 比拟了解”。但 View 能够恰恰是 Web 顺序最难说清楚的中央。

按下面对 MVC 的定义,M 和 C 的分野在业务逻辑(domain logic/business logic)和运用逻辑(application logic),而 View 仅仅是视图。

但在 Web 范围里曾经没那么复杂,由于前端越来越多地承当了运用逻辑的功用(毕竟用户输入都是绑定在 DOM 上的),所以承当“用户和系统之间衔接”的更多是 View。这时 View 其实是“控件”而非“视图”了

提供最优质的资源集合

立即查看 了解详情