http://www.rainsts.net/article.asp?id=272
在电子商务网站项目中，设计人员的关注重点往往集中在业务模式和并发处理上。尽可能容纳更多的并发访问本身并没有什么错，但由于过于强调速度优化而忽略系统维护性的例子也比比皆是。
强调访问速度，在设计上往往会强调几点。
1. 尽可能直接访问数据库，减少中间环节。如此一来，最多就是加个 DataAccessHelper。
2. 尽可能使用存储过程，以便集中精力优化 SQL 语句。
3. 减少中间层，降低中间对象，减少 GC 回收次数。
等等……
这些措施从一定程度上加快了系统的处理速度，达到了设计者的要求。但所有的环节都被严格绑定在特定的“环境”下，相信很多人对于维护数以百计错综复杂的存储过程头疼不已。而电子商务又是一个变化非常多非常快的事业，因此随着系统的运营，我们不得不投入大量的人力物力修修补补，最后一个个都变成了百衲衣，和当初的设想背道而驰。
ORM 提出的初衷就是为了将系统和数据库进行一定程度上的隔离，并使用对象模式来替代平面关系表，最重要的是动态 SQL 构成使得我们可以非常方便地在多个数据库系统间自由切换。使用 ORM，我们可以直接以对象来思考业务模型，而不在将重心放在数据库上。系统自动映射(创建)数据表将开发人员从复杂的数据关联关系中解脱出来。当然，这一切都是要付出代价的，使用动态代码或者反射自然降低了系统的性能和速度，大量中间对象也迫使 GC 回收的次数变得更加频繁，这对于并发量动则十万百万的电子商务系统而言的确是个不得不考虑的问题。
那么这一切当真不可调和吗？回到电子商务系统中来，让我们分析一下。电子商务系统中，并不是所有的模块都是被频繁使用的，并发集中在几个局部点上，诸如分类目录、搜索引擎、主页等，而那些用户注册、认证、登录、订单并没有那么大的使用量。经过对实际的流量的分析，我们确认并发量大的往往集中在信息模块上，商务模块使用量少但复杂度却是最高的。有了这个结果，我们就可以采取不同的策略了。
1. 将系统分割成信息单元和商务单元。
2. 使用统一设计，提供多个 DAL 访问实体类。信息单元使用 DataAccessHelper，直接和目标数据库交互；而商务单元则使用 ORM 系统进行开发。
3. 进一步优化信息单元，为主页等访问流量较大的信息页设置缓存机制，每隔一小时或者更长的时间更新一次，减少和数据库的交互。
4. 使用完全独立的搜索引擎系统。比如 Lucene 有自己的索引数据存储机制，这种机制可以大大降低系统对于数据库的访问，而且I/O级别的访问效率也大大高于数据库。我们完全可以使用独立的机器部署搜索引擎。
基于上述方式，我们可以大大降低系统的复杂度。初期开发的时候，我们可以统一使用 ORM，直到后期再针对性地提供 DataAccessHelper，大大加快了系统的开发速度。而且系统的结构更加清晰，维护起来自然也方便很多。
优先考虑系统架构，减少系统的复杂程度，减少对特定环境的依赖…… 我个人认为要远远比单纯的并发速度重要得多。