laravel系统开发经验(二、视图设计)

Web端网站视图如何设计

 

“视图还要设计?不要弄这些虚的,开发项目,拿起键盘就是干。”不少人看到标题第一眼的想法就跟下面这位年纪二十多岁的程序员一样。

 1559891513180209.jpg

但是好的设计就跟安全用品一样,平时也许不怎么需要用到,但是关键时候会起到决定作用,

视图的设计架构就是如此。

 

目前主流的视图设计有两种途径

1. 后台语言混写HTML,比如php框架里面的smarty模板引擎,java里面的jsp

这种最为常见,但是因为后台语言和前端语言混写在一起,逻辑有严重耦合,加载速度上也有不少影响。

 

2. 前后端分离,后端提供接口,前端接受接口数据初始化前台页面

这种从项目架构来说,是最符合要求的,前端的所有页面可以做cdn加速,也可以放在云资源服务器上,所有的数据都是通过接口传递。后台做后台的接口,前台做数据渲染验证等逻辑,互相分离。

但是这种设计一般只有中型大型公司才会采用,原因有如下两个

1. 人员成本和维护成本

混写的话只需要一个后端程序员,分离的话最少需要两个。后期前台的页面要改动逻辑,也必须找到对页面逻辑数据的人来做。

 

2. 时间成本

分离两端的话,虽然前端前期可以做页面,但是前端的开发还是依赖于后端开发进度,而且二者联调也要花一些时间,联调遇到问题的话可能会比单独混写的时间久一些。

 

目前比较火的前端SPA架构的项目就是这种方式的一种极端化,将所有的业务逻辑都在一个页面里面实现,跳转利用js拦截,从而实现无刷新跳转,用户体验比较好,加载资源也可以重复利用。但是页面SEO处理,以及后期调试维护成本也大大增加(试想一下一个超大型的项目,当初做第一版的人交接工作没有交接好,后面的新人来维护旧项目难度有多大)

 

那么针对这两种视图设计,应该需要注意哪些方面呢?

1. 后端混写

这种视图,一般最好是采用《基础视图+继承扩展视图》的形式来开发,比如后台模板,一般公用的jscss还有视图结构是定义在common_admin.html,其他的具体逻辑视图,比如搜索页面search.html,继承于common_admin.html

其次业务逻辑与视图对应关系上来说,应该是一个操作对应一个视图,一个控制器对应一个文件夹,一个控制器里面方法对应的视图应该要放在一个同一个文件夹内。

对于公用组件如富文本编辑器,图片上传等,采用公用组件引入,到时候便于统一修改。

 

2. 前后端分离

接口需要定义好公用规范,包含但不限于如下几个要点

1. 成功与错误代码,一般的结构类似于这种,code来标识是否成功,msg是提示信息,content是返回正文内容,一般返回数据格式为JSON

        
        {        
            "code":"",
            "msg":"",
            "content":""
        }

2.  用户身份标识,前后端分离之后,后端不能用session标识用户了,那么应该如何追踪用户呢,一般来说,是在用户登录之后,发放给前端一个加密身份令牌token,这个token往往是与用户身份绑定在一起的,每一次前端请求接口都需要传递这个token。平时token保留在本地,如果用户下次登录用旧的token换取一个新token

3. 前端错误跟踪,数据从后端流动到前端,如果中间存在什么问题,如果追踪这个在前期的时候必须考虑到。常见的做法是前端统一请求方法,所有的请求走统一入口,对于错误信息,打印到浏览器控制台,或者汇总到全局变量,然后从控制台查案。这样便于后期项目上线,及时定位问题。

4. 前端项目文档整理,前端项目的源代码,各个页面的详细接口文档,这些必须要详尽,标准就是如果是一个新人看到了,都可以在短时间内直接上手项目。

不过这一点,一般很少有公司做到,因为文档是否详尽,需要一个对于业务十分熟悉而且不会碍于同事面子,保质保量监督写文档的人来处理,这种人太少了。

 

写在最后的话

一般在开发项目里面,大多数都是采用的混写的方式,毕竟写起来还是很爽的,前端页面后端逻辑,一人搞定,要修改直接修改,维护成本也低。对于页面渲染速度和用户体验来看,实际上大多数用户也并不是特别介意。

不过呢,人还是要有追求的,能将体验提升,项目的逻辑可以低耦合,各个岗位各司其职,也是一个追求的目标。


发表评论请留下您的大名
  • 最新评论
  • 总共1条评论
无业医生晨大夫

小白龙 :博主说的安全用品具体是指什么

2019-06-07 15:17:20 回复