数据后台与前端展现

一.问题

现在很多web服务,都是前端展现与后端数据放在不同的内部服务器上。其结构为

1.那些数据可以在html,js中存在

  a.为了安全性,避免隐私数据存在

  b.如果仅仅为了保存一些数据,然后在互动的时候使用,该不该存在?如果不保存这个数据,那么必须到后台去取。

2.那些数据可以在业务逻辑,即前端网站的后台存在?

那些数据会需要暂存到前端的后台吗?

  我觉得一些不会更改的,数据字典类型的数据可以暂存到前端,应该这个数据是基本永远不会变的,而仅仅对数据起到解释的作用,

    a.比如数据表中的字段在界面应该显示为什么名字等等,

    b.有多少个类型的对象,对象可以变,对象类型不会变

    c.或者使用memcache,让它自动的优化那些该临时存放。

  这些数据通用(使用次数多),不变,不易展示于html与js里面(能被浏览器直接看到),所以放到前端站点的后台。

3.数据服务的数据是什么

  一般是基于数据库提供json的数据传输。

二.标准化做法

1.前台的数据表格:

  a.采用bootstrap-table,查询为form的ajax查询的刷新数据。服务端分页(加载数据量为一个页面的数据,翻页要请求后台),

  b.表格的标题显示:表格标题就直接写在html中,写在后台没有必要,这个是很难标准化的。

  c.表格内容显示:这个涉及数据字典,查询出来的是数据库里面的数据,有时候需要将里面的数据转化一下,比如某个状态的英文字转为中文表示。转化如果发生的在后台,就需要对查询列表再次遍历,然后转化,增加了后台工作量;发生在前台,则计算压力在js。(django里面有语言translate模块,这里假设这种状态转化不能通过django里面翻译模块实现。因为同样字符串在不同数据表里面代表不同意思,所以在前端展现也不一致。)

  一般来说,在后台写上数据字典,为了保持一致性,所以数据字典的定义可以在web应用中使用一个模块定义,而页面逻辑可以继承该模块,获取所使用表格的数据字典。前台使用js函数转化。数据字典的定义不必写在前台,这样前台的js转化函数可以复用。不过客户可以通过方法看到原始数据库里面的数据。

  后台,给数据结构传递给context,并且传递tablename 的字符串,设置为bootstrap-table的table标签 id,以及组合成查询条件form 的id;这样就会使得代码极度复用。

def data_define():
    table_dict={
        "table1":{
            "field1":{
                "normal":"正常",
                "error":"异常",                
            }
        },
        "table2":{
            "field1":{
                "good":"",
                "bad":""
            }
        }
        
    }
    return table_dict

  前台引用该数据结构解释某个字段

function translate_field(value,row){
    current_table={{ table_dict.tablename }}
    field_def=current_table[this.field]
    return field_def[value]

}

二.web应用

  web应用包括前台界面以及后台页面处理,部分业务处理,以及需要向后台发送api应用发送请求

  a.html以及后台页面处理:html页面功能为展现,前端验证用户输入,根据状态决定控制逻辑。后台直接处理该页面请求的函数,应该只涉及前台页面输入验证,或者查询其他模块请求获取用于展示的数据。不要写可能会被复用的处理逻辑,不要写别的系统性的体系中的零件。直接在这块里面写复杂逻辑会使得代码分散,比如价格控制,此类逻辑应该用一个专门的模块来处理,而非分散在各个页面处理代码中。由于价格控制是一个整体,而且很可能体系会进行变换,分散的代码将使得维护变得困难。  

  b.请求api的数据:为了使得程序更加分布式,向数据库处理的应用是独立的,高性能的。部署在集群当中。web应用向api请求数据。我觉得应该就api的每个接口都统一写成函数调用。而不是,每次请求api就需要自己写一个url请求的代码。然后判断返回值之类的。因为这类的请求会多次发生,会被前端url直接调用,也可能被web的后台调用。所以写成函数,大家都能够很方便调用,不容易出错。

  c.ajax请求处理:所有ajax请求都会对接收到的反馈进行处理,而对错误也进行反馈。如果希望所有处理保持一致,那么对于success的ajax请求应该使用建立单独的函数提供每次success调用;同样error处理相同。这样希望替换某种出错处理提示内容样式,不需要去每个ajax请求中寻找,只需要更改单独的函数。基本每个出错提示信息显示样式都相同,不同只是文字内容。

     d.模块独立可运行,独立可测试:多个模块的程序组合的情况下,在web中,需要调用其他web应用的接口什么的,为了保证自己的模块独立可测试,在引用其他模块的时候,加上try 再import,否则程序引用一多,很可能程序上线组合完成,再调试不了。因为可能东西揉合在一块了,必须保证单独模块的独立可运行。独立可测试。

原文地址:https://www.cnblogs.com/yasmi/p/5341079.html