acws框架体会：视图的作用 view 取代fid部分作用

问题来源：如何处理表间取值？表的设计，视图的运用，表取值过程的转化

建表时，有实际意义的外键：

    之前模仿hibernate建表模式，此模式最重要的特点就是为每一个表建立独立的主键外键，主键为 oid， 外键为fid， 主外键与其他有实际意义的字段值独立开来，这样设计的优点在于 将维 护表之间的关系和修改表字段的值分离， 对其他字段的修改将不影响表与表间的关系。如做过的小项目账户客户，外键fid只起外键链接作用，本身fid保存的是oid的值，这里的fid只维护关系但没有任何实际业务含义。

    以外键的作用划分，我们可以把外键分为两种：没有实际业务意义的fid和有实际业务意义的reqion_id。 没有实际业务意义 的fid的主要意义在于建立表连接维护表的关系。 有实际业务意义的 reqion_id的主要意义在于取值，取另一个表的字段值，且那个值是可变的。

    当设计客户区域维护小项目的时候，外键reqion_id不单是纯粹的外键，而有了其实际意义，用式子说明： c.reqion_id ==r.oid得到 r.name 。这样的设计的最终目的是以 r.oid 为中介辅助得到 r.name ， 而且 r.name 在r表中可变的。当遇到 有实际业务意义的外键，从外键值转化到要取的值有一个转化过程，这个转化过程在 客户区域维护小项目中在程序端在dao里是实现的。而在acws中，这个过程通过表和view实现。

 

    问题再进一步就是今天所要处理的问题： 如何 处理表间取值？表的设计，视图的运用，表取值过程的转化。

 

    在acws中，考虑到程序端已经对客户端所传参数进行处理和过滤，要储存到数据库的值相对来说是安全的具有实际业务含义的。表间太多连接关系不利于维护，表间取值所需要的外键直接降为字段，作用还是作为外键的意义存在。事实上这样是可行的，如上有述， 程序端已经对客户端所传参数进行处理和过滤， 要储存到数据库的值，首先这些值的值域是限定的，这个限定的意义作用和以前外键的取值有限定的约束是一样的。

    上段总结：表的设计， 取消外连接 降外键字段为普通字段，但作为外键意义存在，并且这个字段的值是受到外键意义约束的，有程序端传参保证。

 

  

    表的设计模式确定以后， 取值过程的转化有两部分 ：

    1.查询

    查询是通过视图，视图包含已取到的值字段，这个字段是通过表连接得到的。参见v-customer。过程类似于 c.reqion_id ==r.oid得 到 r.name 。

    2.修改和保存

    过程相反，得到的参数是 r.name，要通过 r.name得到 c.reqion_id从而保存 c.reqion_id。

    具体从数值上 从r.name到 c.reqion_id的转化过程是通过下拉框实现的。acws具体封装下拉框的过程已经被封装，是由一个函数实现。反过来说，表间取值的具体应用即是为了在页面显示一个能取值的下拉框。

    举例：sp_management.js中

CustomerManager.getCustomerTypeList(function(jsoList){
        filljsoListToSelect('QU_CUSTOMER_TYPE',jsoList,'COMPANY_TYPE_NAME','BO_COMPANY_TYPE_ID',0);
    });

    这是一个类似于request.onReadyState(callback);函数。此函数意义丰富，封装了很多东西，功能很强大。

    对于取值过程的反转化在此函数中的体现就在这四个参数：

    1.filljsoListToSelect 与html页面的<select>有关。意思是填充 页面 的<select>的<option>的value。

    2. 参数的对应

    2.1 QU_CUSTOMER_TYPE是运营商类别<select>.id||name

    2.2 jsoList是java类方法返回对象

    2.3 COMPANY_TYPE_NAME，BO_COMPANY_TYPE_ID都是公司类型视图的字段，同样包含于jsoList，是jsoList的属性名

    2.4 COMPANY_TYPE_NAME参数意义是作为显示值

    2.5 BO_COMPANY_TYPE_ID参数意义是作为真值