EAS使用UUID作主键已经很多年了，K3 HR也是。但遇到的问题应该都不少，今天在Martin Fowler的书中读到这么一句话：GUID唯一的缺点在于生成的串比较大，这可能会成为一个大问题。后面还紧跟了一句：长键总是难于输入也难于读写，这也会带来性能问题，尤其是对索引。呵呵，看来Martin大叔是也是深有体会的，其实我们后来遇到的很多问题都是与之相关的。1）数据太大导致数据库过大。和K3同等数据量的账套相比，EAS的账套要大许多，这中间GUID的贡献就“功不可没”2）索引问题：使用GUID之后关联属性都是大字符串，而这都是索引字段，于是乎索引性能问题出来了。
延迟加载/惰性加载（Lazy Load）
一个对象，它并未包含所有数据，但是知道如何获取这些数据。 上述是定义，但我觉得这个定义并未体现出LazyLoad的精华，因为我们真正需要的不是它知道如何取得，而是能够根据需要取得，从而根据实际情况来优化性能或内存。
标识映射（Identity Map） 通过内存映射标志，确保每个对象只加载一次。 上面是定义，实际上就是在内存中维持一个对象缓存（通常是Map缓存），每次获取对象的时候，先到缓存中获取，不存在再访问数据库，当然需要考虑更新时的同步。这不是个什么新鲜东西，给一种常用的做法赋予一个深奥的名字就是大师们常干的事情。对于这个模式我没有太多个人的想法，只有以下2点： 1、Map的层次。如果一个对象会存在并发更新，则只能作为会话层缓存映射。如果一个对象属于只读对象，则可以作为全局缓存映射。在EAS的Cache中提供了CacheRegion的划分方式，结合Session对象，我们可以灵活定义映射层次。嗯，我认为Session是个好东西，如果不被滥用的话。 2、映射的大小：由于JAVA虚拟机的要求，在32位的服务端对内存是有严格要求的，基本上就在1.3G左右，以前元数据是做了映射缓存，可惜占用内存太多，被无情地Cut了，改为采用惰性加载＋WeakReferrence的处理方式，我还是认为缓存起来比较好，以前也思考过对应的方案。其中和Anderson就讨论过是否可以通过专用的CacheServer来满足需求。以前没有集群方案，现在有了集群，似乎该方案开始具备可行行了
InitialContext ic = new InitialContext();
这句代码很是容易，在JAVA入门学习过程中，应该每个人都写过。不过是否每个人都知道这句代码做了什么事情呢？为什么后面的代码就像是魔术师的帽子，可以从里面拿出你所需要的一切？
如果对于上述问题不清楚的朋友可以参考以下内容：
从单机编程转向 EJB 技术和分布式计算这些更复杂领域的 Java 开发人员常常会陷入困境：编写成功地游历 JDNI 迷宫的代码会很困难，多计算机和配置也增加了出错的可能性。在本文中，EJB开发人员
工作单元模式（UOW） 这个模式的作用在于维护一个对象列表，能协调变化的写入和并发问题的处理。这个说法过于抽象，实际上我们可以将其想象为一个特殊的容器，一个对象被构造出来后就丢到这个容器里，对于这个对象的任何变动，容器都能知晓，最后由容器来决定提交的时候要做什么。 举个最直接的例子：我们有个操作，需要更新一张凭证的某个科目，在直接写SQL的过程中很直观，我们可能会通过Update
一点想法，还不够成熟，暂记录在此。
不常用操作：指执行频率在1次/天，甚至更少的操作。
常用操作：可以分为业务操作与辅助操作。
业务操作：如：单据提交、审核、查看等关键业务功能的操作。
辅助操作：为完成主要业务功能，而进行的必要操作。比如：为提交单据，必须进行F7查询、录入物料、科目等。这里提交是业务操作，而F7、录入物料、科目属于辅助操作。
用户对于辅助操作要求非常高，一般不宜大于2秒。而对于业务操作相对要求比较低，可以放宽到5秒。
此文主要是转贴，不过在转贴前我还是有些个人想法，AOP这个概念已经出来很久了，实际上EAS BOS也有一定程度的应用，正如CoreJava 在DynamicProxy一章中所述：动态代理对于应用程序员来说不是很常见，但是对于系统编程来说却是非常重要。我想这里的应用程序员应该可以对应为EAS项目组的开发人员，系统编程则应该对应BOS及基础部门的开发人员了。
由于今年一个可预期的工作是对BOS一些底层功能进行重构，因此如何保证现有产品的稳定，同时能够改造有缺陷的实现成了一个焦点问题，我想AOP应该是可以大有作为的<ZT>
20世纪著名建筑设计大师、家具设计大师和城市规划大师小沙里宁有一条非常经典的设计理念：
“Always design a thing by considering it in its next larger context - a chair in a room, a room in a house,