架构模式的最终目标都是将不同的逻辑分离出来,即逻辑分层,降低项目的复杂性。如业务逻辑与展示层逻辑的分离,某个层逻辑的变动不会造成其他层的变动。
比如后端的MVC(Model-View-Controller)架构中:
-
数据逻辑(Model):dao、service层处理数据并转化为View可用的Model;
-
交互逻辑(Controller):controller层处理前端的请求
-
渲染逻辑(View):将Model渲染成用户可见的视图(html),但前后端分离后,可见View的用户成了前端程序员,因此通常是将Model渲染成Json。
渲染逻辑基本不用自己写逻辑,都有现成的库了,如spring mvc会帮你处理好。
又比如前端的MVVM(Model-View-ViewModel)架构:
- 数据逻辑(Model):数据获取、处理
- 交互逻辑(ViewModel):处理用户与View的交互。
- 渲染逻辑(View):将model渲染到View中。。
为啥MVC和MVVM的目标一样,却又不用的名称呢?可能是大家觉得交互逻辑处理方式不一样,如数据绑定,所以就以名字来区分吧。。
比如说,前端框架Vue基本实现了MVVM,它的ViewModel提供了数据绑定的功能,Model改变时,View则自动改变,无需手动修改View的内容。这样使得程序员更多的专注于组件逻辑的编写,程序的复杂性大大降低。