Web系统开发构架思考

《Web系统开发构架思考》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、Web系统开发构架思考简述目前大部分系统的架构图，虽然有些系统采用分布式架构，层与层之间使用了远程调用框架，但是本质上都逃不开上面这个架构设计。这张图是一张比较合理的图，在实际开发里最常发生的事情就是控制层（Control）越过服务层（Service）直接处理下面的资源。前后端耦合的问题主要发生在控制层（Control），控制层是前端和服务端交互的边界，但是在开发过程中控制层（Control）和服务层（Service）常常混淆不清，这就是前后端耦合度高的重要原因。因此要前后端解耦，就是要划清控制层的边界，控制层到底该属于前端还是服务端，在MVC模式里控制层作用是调度，控制层不是写

2、业务逻辑的地方，因此将大量业务逻辑写到控制层其实是违背了MVC模式的思想，同时控制层是前端和服务端通讯的桥梁，其实控制层是参入了前端的工作任务，既然控制层要剥离业务操作同时控制层也要参入前端应用的开发，那么将控制层归为前端的一部分是完全合情合理合规的。前后端分离的终极目标应该是前端和服务端是完全独立的项目，前端项目包含上图里的浏览器和控制层，服务端项目包括服务层、DAO层等等，前端项目和服务端项目以高效的远程调用框架做通讯介质，项目开发时候前端项目做前端的事情，服务项目做服务端的事情，这样就让服务端开发的人员没有机会在控制层乱写代码了，保证了Web前端环境的纯粹性，最后生产发布也

3、要独立部署，这样就达到了前后端真正解耦，但是前后端的沟通机制也是不可或缺的，我觉得它们之间的沟通使用高性能的远程调用框架，前后端相互约定通讯报文格式。.其实不管服务端还是前端宏观流程无非是输入数据和输出数据处理，但是服务端要把心思花在数据处理上，前端要更多关心的是输入输出数据时候的用户体验操作，服务端开发最大的问题就是违背MVC原则，代码编写的随意性，而前端不管出于安全还是性能考虑，最好是尽量少牵涉业务。前端和后端通讯层的独立，会将前后端进行真正的解耦，前面讲到前后真正问题就是前端和后端技术路线不一致，但是传统Web开发里前后端又要融为一体，这就导致前后端很难做到专业化分工，对于

4、前端应该尽量弱化通讯级别的开发工作，前端通讯编程只要知道调用哪个接口，传什么参数，怎么处理响应信息就行了。这样就能让前端和后端实现真正的专业化。做到了这些，就不会发生开发时候前后端边界不清的问题了。专业化分工技术团队做Web开发也可以说是B/S架构开发，B端和S端从技术体系角度而言异构性很大，换而言之就是B端使用的技术和S端使用的技术不适于同一个体系，这样的结果导致实际开发中，很难做到专业分工，如果项目开发过程中管控不到位，这样的问题可能会影响到整个项目的开发质量，因此前后端分离的目的之一就是要做到专业化分工，提高项目的质量和开发效率。随着技术的发展，当下的Web开发形势已经和以

5、前有了很大的不同，早期的Web项目是一个封闭的项目，用户从浏览器里看到的页面直到后台数据库都是在一个项目里集成的，而现在Web系统的规模越来越大，中大型的Web系统是一个开放式的系统，开放型的系统用户在浏览器发起的请求可能会转发到外部的系统里进行处理，或者是本地的系统和外部系统一起完成请求的处理，此外有的请求可能不会直接请求数据库，而是请求缓存服务器，这些变化几乎都是发生在Web系统的服务端，前后端耦合度很高的Web系统服务端的复杂度提升必然带来了Web前端的复杂度的提升。因此Web前端从系统架构的角度也需要更加专业的管控，管控的作用之一就是前后端进行分离，降低前端对服务端的依耐

6、性。富客户端应用的普及导致Web前端技术开发更加专业化，Web前端工程师成为一个独立的技术岗位，Web前端开发技术的难度也越来越高，前后端的分离就是为Web前端开发营造一个良好的开发环境，不要让前端工程师被一些不可控的外在因素所影响（例如：前后端的耦合性），最后导致前端不能专心致志做出更加好的作品。所以，前后端分离是让前后端更加专业化，在技术和管理上将前端角色更加明确，更深入的挖掘前端开发的价值。让前端的东西项目化，工程化，提升前端技术，它也是需要大量的系统架构，开发规范，自动化压缩混淆，自动化发布，前端监控和分析，前端优化等等前端组件化开发，不管这个组件是UI层级，还是java

7、script开发层级，都脱离不了该公司业务产品的模式，其实看看像网易，新浪这样的门户网站的前端应用组件，它们用于做门户很合适，但是用它来做公司应用软件可能就不是太好使用，因此对于组件要有一个清晰的认识，我觉得可以把组件按业务场景分类，这里我可以举个例子，如果这个公司有给门户使用的组件，而这个组件很适合门户，应该把它归为门户组件，如果某些组件适合做网站后台管理的，那么就列为后台管理组件，如果某些组件能跨多了业务场景则标记为通用组件。做分类的原因是为了理清组件的应用边界，这样我们可以