zoukankan      html  css  js  c++  java
  • 数据后台与前端展现

    一.问题

    现在很多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,否则程序引用一多,很可能程序上线组合完成,再调试不了。因为可能东西揉合在一块了,必须保证单独模块的独立可运行。独立可测试。

  • 相关阅读:
    HDU 2433 Travel (最短路,BFS,变形)
    HDU 2544 最短路 (最短路,spfa)
    HDU 2063 过山车 (最大匹配,匈牙利算法)
    HDU 1150 Machine Schedule (最小覆盖,匈牙利算法)
    290 Word Pattern 单词模式
    289 Game of Life 生命的游戏
    287 Find the Duplicate Number 寻找重复数
    283 Move Zeroes 移动零
    282 Expression Add Operators 给表达式添加运算符
    279 Perfect Squares 完美平方数
  • 原文地址:https://www.cnblogs.com/yasmi/p/5341079.html
Copyright © 2011-2022 走看看