MUO简介.docVIP

MUO上下文简介 MUO Managed-User-Object 被管用户对象，通过它可以扩展定义用户在应用中的会话信息。 扩展用户会话信息 在一般J2EE应用中，存储一个用户相关会话信息是通过HttpSession设置用户的相关属性。 对应着在EOS6也提供了相应的上下文作用域存储用户信息，即SessionContext的IUserObject。 默认userObject已提供一些常用的属性，可以在用户登录后，对这些属性进行初始化赋值。 但通常一个系统的用户信息不止只有这些，那么就需要进行扩展定义，有以下两种方式： ① 通过userObject提供的扩展属性attributes进行设置。Attributes是一个Map的属性对象，可以对其任意设置值。如： userObject.getAttributes .put “empid”,empid ; 对应在页面流的赋值操作：s:userObject/attributes/empid ② 通过user-config.xml定义MUO相关扩展属性。如： module name Session-Manage group name Managed-User-Object configValue key ”empid” sdo:Int 优劣比较 那么这2种方式到底有什么区别，他们分别在什么情况下使用？ 它们本质上都是通过HttpSession保存数据。从J2EE分层原则上看，它们都是应该在Web层 或者说是展现层，页面流 的操作，而不应该属于业务逻辑层 逻辑流 。 ? 第①种定义的好处就是，你只能在页面流通过“s:”的方式获取会话中的数据，从而有效的隔离了逻辑流跨“层”的操作，而逻辑流想获取会话中的值必需以参数形式传递。 不便之处就是，在Studio没办法提示attributes有哪些属性可操作。 第②种定义的好处就是，你可以在逻辑流中通过“m:”的方式获取会话中的数据，而省了参数定义。但EOS6之所以允许这么处理，是因为从页面流调用逻辑流时，会将会话中的数据“拷贝”到MUO Context中，处理完后再将数据“拷贝”回会话。 但从设计的原则上来说，一个操作业务的接口应该是清晰的，需要避免隐晦的参数来源；第二：采用“m:”方式在页面流和逻辑流分开部署的结构上，不易扩展，可能会带来性能上的损失；第三：在逻辑流采用“m:”获取MUO或Session上下文的内容时，当把逻辑流暴露为对外调用的服务时，要注意参数的正确性，因为“m：”获取的参数值为本应用的会话数据。 另，在MUO或userObject/attributes定义的扩展属性值，必需是可序列化的对象！尽量简洁！ UserObject说明 用户对象是EOS6默认提供的系统对象，存储着当前会话用户的相关信息. 创建 UserObject对象创建是根据user-config.xml的配置： group name Accessed-Mode configValue key Portal false 如果Portal设置为true,默认在第一次请求时会自动创建userid为guest的UserObject对象，存储在session中。 如果Portal设置为false,则在用户系统登录时需要手动创建。 为了能够将创建的UserObject对象，纳入EOS6提供的在线用户管理OnlineUserManager，必需在登录相关的逻辑流中定义一个UserObject的变量，调用com.eos.access.http.OnlineUserManager.login方法进行构造用户实例（ABFRAME封装中已经调用保存）： ? 销毁 销毁UserObject，即注销当前用户Session,可直接在JSP文件里调用invalidate 方法： session.invalidate ; 非Portal的访问模式可在运算逻辑里判断用户是否存在，可使用以下代码判断： DataContextManager.current .getSessionCtx .getUserObject 引用类型：com.eos.data.datacontext.IuserObject.java 字段说明 类型 名称 说明 Long userId 用户登录名 String userMail 用户邮箱地址 String userName 用户名称 String userOrgId 登录机构内部ID String userOrgName 登录机构号 String userRemoteIP 登录人员IP String attributes/empid 机构人员ID String attributes/operatorid 操作员ID与empid一致 String