从逻辑解偶到物理解耦再到先后端分离

 

逻辑解偶：

      MVC是一个表现层的架构模式，它把咱们的Web应用划分红模型，视图，控制器三部分。从逻辑上解耦了系统的业务逻辑和表现逻辑。但问题在于MVC的各部分并无一个严格的定义，去指导咱们何时使用M何时应该使用V，这些判断都取决于咱们以往的项目经验，因此对于工做应验很少的人来讲要彻底理解而且合理应用并不容易，甚至可能还会引入没必要要的复杂性。

先后端耦合：

      因为模版文件和静态demo由项目中不一样的角色来维护，前端修改demo，须要通知后端去同步模版，相应的模版变动也要通知前端去同步demo。如过二者不一样步就会产生问题。另外后端套vm模版须要修改HTML，后端不擅长作这些事情，就比较容易出问题。工做可能会遇到这样的场景，前端同窗把静态demo交付给开发，开发拿到demo套后端模版，接着进行先后端联调。联调完成后，一直运行的很好。某天后端同窗来过来讲界面有问题，通过反复沟通，花费时间排查问题。发现原来是修改vm模版文件的时候HTML标签嵌套错了。

先后端分离：

       开发中分离关注点有助于屏蔽项目的复杂性，下降维护成本。前端和后端的分工协做就是为了更好的实现关注点分离。然而因为vm模版这块职责不清，当前这种协做方式致使先后端耦合较多。经过先后端分离，前端关注界面(视图)和界面交互（控制器）的实现，后端关注业务功能和持久化的实现。后端经过接口的形式提供数据给前端使用，后端不用关心数据怎么显示在那显示。前端不关心数据从哪来的好比数据库，缓存仍是其余什么地方，也不关心数据是怎么来的，好比通过了那些复杂的逻辑处理。专业人员作自身擅长的领域，使得项目中表现和业务逻辑的物理解耦，进一步提升了先后端开发人员犯错门的门槛，也能够有效提高项目的可维护性和不一样角色之间协做沟通效率。

怎么实施：

   若是让前端开发参与到java工程中接手项目中的视图和控制器这个明显不符合实际。 javascript，是每一个前端前端工程师的必备技能，有不少成熟的基于nodejs的web mvc开发框架。能够很容的帮我实现控制器和和视图的功能。我认为前端工程师不等于浏览端器工程师，和界面、界面交互相关的技术实现都应该属于前端范畴。

 

 

 

 

和后端约定数据接口面向接口开发，

 

分离关注点：

bui迁移的 vmcommon 的问题就不存在


痛点是是什么，问题。
要不要作一个node web 框架
问题：数据经过http传输会不有性能问题
解决当前的ued kpi（擎天柱）仍是先后端分离
咱们要作先后端分离吗：
先后端分离，midway