MVC, MVP, MVVM等UI层架构模式的学习总结

 
这两天看了很多前端的架构模式，看得眼花花，思路没有整理清楚，反而越来越乱。难道我们真的需要字斟句酌的抠字眼，去分辨哪种模式最优秀？去争论哪种模式的哲学思想最有高度最有深度？不！
幸好看了个老外的文章，才发现这些模式其实并不是真正要关注的点。
 
仔细阅读了这篇老外的文章两遍，发现开发各种前端框架的巨牛就是脑洞大，不囿于形式约束，而是根据实际需要来定义模式。
 
 
MVC, MVP, MVVM都是应用于UI层设计的架构模式，用于分离关注点，使得代码更加容易理解和维护。
 
说起关注点，扯到我们开发人员应该关注的事情上来说，很多人关注的点搞错了。我们该关注是功能需求以及需求的变化方向，而不是脱离实际项目去研究那种架构模式更好。真正有价值的架构，是适合实际项目需求的架构。
 
MVC本意是什么我不是太清楚，看了不少大牛小牛一家一个不同的说法，因此也没打算再去弄清楚。但我很清楚这是一种很好的责任划分方式，一种关注点分离的指导思想。
 
你可能会说MVP比较好，好吧，我以后就只用MVP了；他说MVVM更好，也行，我以后都用MVVM；大师说错了，RVP才是前端最潮的模式，那行吧，我以后都用RVP。
 
我一秒钟几十万上下，没那个时间去扯M，V，VM，P... 的精确定义...
 
 
我打算就用MVC这个词来解释问题，可能以后会换个词，但也无关紧要。重要的是把UI层在逻辑上分成3块的思想。
至于什么 thin M还是 strong M，thin C, strong C，是你的事情。
 
业务逻辑要放在M还是放在C（或者是MVP的P或MVVM的VM），你不可能通过跟别人撕逼来得到正解。你的项目是你在负责，功能需求及可能的需求变化只有你才最清楚。项目搞砸了，跟你撕逼的人只会说你蠢，顶多客气点说“我都是为你好，可惜你学得不对”。
 
因此我的想法是，UI层按关注点分离划分3块：数据，视图，控制（你要不想叫‘控制’就自己随便想个别的词，比如呈现器什么的）。MVC / MVP / MVVM / RVP 随便哪一个都好，都是3块，这些模式都有可以参考的设计思想，却不意味着你一定得套用其中一个。而是要根据你的实际项目，根据功能需求及可能的需求变化方向，来确定数据，视图，控制这3块的依赖关系和通讯方式。
 
功能需求及可能的需求变化方向，这才是你要关注。
 
 
 
 
 
 
 
posted @ 2016-08-09 02:36  wildfire555  阅读(211)  评论(0)    收藏  举报