应用服务层的缓冲设计策略

        最近在开发一个n-tiers的应用系统，应用服务层主要以WebService作为服务的提供方式。为了提高系统的效率，在服务层做业务模型数据的缓冲是必要也是必须的。在具体设计缓冲的对象模型时，得出以下几点结论：

1。缓冲是可写的。即更新业务模型数据时，不仅需要更新到数据库，同时需要更新缓冲。比起模型变更后清空缓冲再重新加载的方法，此方法可以提供更好的性能，但必须保证缓冲和数据库的数据的一致性，这也无形中增加了对系统可靠性的高要求。

2。业务模型更新的唯一途径是经由系统提供的服务接口。对于直接操作数据库更改模型的做法应该杜绝，因为这与缓冲策略是背道而驰的。

3。以ADO.NET中的DataSet作为被缓冲对象的数据结构。通过使用DataView提供的筛选、排序等特性可以简化从缓冲中加载数据的实现。

4。被缓冲数据的粒度。对于同种类型的数据（通常在一张数据表中的数据），我认为一次性加载到缓冲中比较好，比起增量缓冲（即用一个加载一个）的做法，此方法实现简单、效率高，而且从系统长期运行后的效果看，最终同种类型的数据都将被遍历、即都被加载到缓冲中，那晚加载不如早加载，“早投资早享用”啊！但我也有所担心，使用DataSet一次性缓冲大量的业务模型数据，可能会占用大量的内存（我现在设计的系统估计得有200M左右），不知这会不会是成为系统性能的瓶颈。这有待系统成形、测试后才能得知，毕竟在系统设计的初期，概念的完整性和统一性以及实现的简单实用性才是最重要的，至于性能问题只是放在第二位的。

5。需要考虑应用服务集群时的缓冲策略。在有多个对等的应用服务形成集群服务时，当一个服务的缓冲更新时，集群中别的服务需要与其同步，以保证各个服务缓冲中的数据都是数据库中被缓冲业务模型数据的完整镜像。