MUO

MUO(Managed-User-Object)被管用户对象，通过它可以扩展定义用户在应用中的会话信息。 

 1、扩展用户会话信息

在一般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</configValue>         </group> </module>

2、优劣比较 
那么这2种方式到底有什么区别，他们分别在什么情况下使用？ 
它们本质上都是通过HttpSession保存数据。从J2EE分层原则上看，它们都是应该在Web层(或者说是展现层，页面流)的操作，而不应该属于业务逻辑层(逻辑流)。 
  第①种定义的好处就是，你只能在页面流通过“s:”的方式获取会话中的数据，从而有效的隔离了逻辑流跨“层”的操作，而逻辑流想获取会话中的值必需以参数形式传递。 
不便之处就是，在Studio没办法提示attributes有哪些属性可操作。 
   第②种定义的好处就是，你可以在逻辑流中通过“m:”的方式获取会话中的数据，而省了参数定义。但EOS6之所以允许这么处理，是因为从页面流调用逻辑流时，会将会话中的数据“拷贝”到MUO Context中，处理完后再将数据“拷贝”回会话。  但从设计的原则上来说，一个操作业务的接口应该是清晰的，需要避免隐晦的参数来源；第二：采用“m:”方式在页面流和逻辑流分开部署的结构上，不易扩展，可能会带来性能上的损失；第三：在逻辑流采用“m:”获取MUO或Session上下文的内容时，当把逻辑流暴露为对外调用的服务时，要注意参数的正确性，因为“m：”获取的参数值为本应用的会话数据。        
注意：在MUO或userObject/attributes定义的扩展属性值，必需是可序列化的对象！尽量简洁！