开发者学堂课程【高校精品课-厦门大学 -JavaEE 平台技术：详细设计-动态模型设计】学习笔记，与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/80/detail/15972
详细设计-动态模型设计
下一个问题就是要创建对象，很多人认为不需要，理由如下：第一，之前提到过其逻辑、对象是不重用的，如果是原来的（类似大富豪游戏），其所有的对象都在内存中，创建完成之后，下次使用时能重用其之前的对象，创建完成是有意义的。
但是在此结构处是一次请求完成后全部对象都不能再使用了，下次请求发送过来全部都是新的，需要从数据库中全部找出来。创建出对象的意义是用完就不再使用了。
而且，对于此业务来说，不用的东西有不同的要求，比如要去改查一个用户，改查一个权限，可能会需要 User 属性。
但对于当前要做的任务，一个用户的权限至是什么，所有的 User 属性都没有意义，有意义的是关系 Role 和 Privilege 权限在第几位上。
其实有意义的是关系和 Privilege 对象的一部分属性。意味着如果要创建对象的话，要创建一个空的 User 对象，关键是 User 对象要知道有多少角色，角色对象早知道有多少权限，权限要知道每一个权限的具体位置，有这些东西足以得到最后需要的东西（权限制），换一种思路，能不能不创建这些对象，创建对象不浪费，不需要放在内存中，又不要重用，最后需要的是权限制，可以把此问题变成一个算权限制的问题，就是Privilege对象要知道权限制是多少， Role 对象早知道权限至是多少，User 对象的权限制是多少，传统的角度上来说，本来是需要把对象模型构造出来，然后在每一个对象上做一个算权限制的方法，然后去完成操作过程，当然也可以算出 Privilege 对象的权限制，再通过箭头算出 Role 的权限制，即全部是倒程来完成权限制的计算，只算权限制，而不建立对象模型，因为对象模型没用，只做最后的结果。
只算权限制来得到最后需要的权限制，接着用一个动态模型来展示权限制的算法：入口是 User Dao,它是不需要写名字的，但是后面的需要写名字，它是一个 UserDao 的对象，在上面写一个方法，方法叫 gapPB,传进去的是一个 User 的 id，登入上来之后，用户名，口令，焦点证券就会得到用户对应的id,不是因为用
户名得到的。
接下来使用此id去询问User Dao的权限制是多少，返回的是一个用户的权限制，用户权限制不需要创建User对象，首先需要去掉 Usernodmap，就知道User有多少room,让room的对象告诉这些room的权限制是什么，若得到了这些Role的权限制，就把其并起来即是得到的权限制，因此在User Dao中所做的代码只是说每一个Role有多少Role,其Role的权限制是多少，然后将其并起来就完成了。
要去掉 urm UserRoleMapper,之前提到原则上使用自动生成的方式来操作此Mapper,但是实际操作中会发现对于此Mapper来说，自动生成生成了四个函数，增删改和差，但其实对于 UserRoleMapper 来说，改是没有意义的，它其实只有增开或删除一个角色，不会做改的操作，其查询是非常特定的，自动生成自己生成的查询是所有字段都会查询的，但是在 UserRoleMapper 中数据表拿出来看一下，如下，在其中有意义的字段是 Role id和User id,其他的都没有查询的意义，自动生成会给所有的字段可以查询的条件去做查询的，即不会用主键查询，也不会用角色和用户查询，只会用 Role 和 User 查询，因此对于如此的 Mapper 就会感觉到不熟悉，对于 Mapper来说，原则上会自动生成，但是对于如此的 Mapper 来说会少写两个方法，根据其User id 来查询角色，另一个是根据角色来查询 User id,但是根据角色来查询 User id 早知道 API 中有多少用户，这个决定另一个方法是否要写，不必要两个方法都写，先写一个方法，此上是一个手写的方法，没有把其中的新增和删除保留，修改的方法去掉，没有必要，查询的方法也去掉，没必要。在里面手写一个查询的方法，即 getRoleUserid,得到的是一个 Role id 的列表，即正常查询数
据的事物，不需要去返回一个对象，做法就是要针对里面每一个 Role id。
把其 id 拿出来去查询它的对象的 Role 的权限制是什么，其中间还有一段代码是做循环 look 循环，要从 Role id 中得到每一个 rid,跳一步到Role 的 Mapper 中去得到rbits，即一个角色的全限制。ger RBitsrid,此 rid 是 rids 的一个局部，里面有其每一个元素，如此就能得到每一个Role 的bits，接着把所有的 bits 并起来就是返回的 RoleDao 同样也不需要把Role对象构造出来，它不使用RoleMapper,而且使用 rpm,rmp 同样需要把其修改删除掉，查询使用自己写的方法（Role Privilege）,同样去调用其 getPrivilegeBrole id（rid）, rid 即上述的 rid,得过来之后会得到 pids（集合），即权限中所有的 pid,同样类似的方式去调用其pDao,因其是一个集合，所以是Role,调用去 pdao 去得到其 pbits=getbitsPBByid（pid）,同样把所有的 pbits合起来就会得到要返回的rbits,对于rdao来说，其调用的是 pmMapper,得到 bit_index字段，用其已经生成好的，得到 pivBo=getobjectByid（pid）,在 po 对象中，可以写一个业务方法，根据 bit_index 去产生其权限位是多少，此方法可以写在 Prive 对象中，因为在数据库中存储的是它的位置，需要得到一个
bitMappwer 字符串。
因此最后调用 Privilegepo 对象去得到pbit,将 pbit 合起来就是最后的 pbits（注意此处不能使用get,因为po对象对get是有敏感的）此上是计算全限制的整个过程。
最后计算完成后，将其放入rids的缓存中，下次用户在调权限时，就去rids缓存中看其对应的位置是否有权限，若有权限，则可以操作，反之不可以。如果在rids中找不到该对象，则可以调用另一个API（计算全限制），将其再算一遍放入缓存中。
因此两个API都会进行同样的操作，这两个同样的动作在 UserDao 的代码中，意味着 UserDao代码中前面要加一个判断，判断当前的缓存中是否有此bits,若有直接拿
出来，若没有则去查询，查询到后放入缓存中，这是针对单个用户来说的。
如果用户有代理关系则在前面再加一段，观察其代理关系是什么然后代理关系再去调用单个用户的方法，因此真正是前面再加一个去查询它的代理对象和它自己的bits,然后把两个 bits 合起来的方法才是在权限中调用的方法，在如上提到的方法中
前面要加字段去判断rids中间是否有缓存。
若有缓存直接拿到bits,没有则按以上操作去计算，计算完成后再参照流程运行。
