在程序中粗粒度和细粒度方法的选择权衡

为什么要用BusinessFascade层，以前在做5层架构的程序时，写出的代码中BusinessRule类中的方法与BusinessFascade中的方法是一一对应的。虽然理论上知道BusinessFascade只是一个Proxy的作用，但是并没有体会到它的妙处，今天看到《分布模式》一章，有点豁然开朗了。



在面向对象模型中，经常有很多规模较小的对象，他们有较小的方法。这样就提供了很多机会来控制和替换某些行为，还可以用良好的命名是应用程序更容易理解。然而，这种小粒度动作将导致大量对象间的交互，而且这些交互通常需要很多的方法调用。

在一个单一的地址空间内，小粒度的交互工作的很好，但是当你在两个进程之间作调用时，这种良好的状态就不存在了。远程调用的开销很大，任何对象可能被作为远程对象使用时，经常需要一个粗粒度的接口来减少完成某些任务所需要的调用次数。

[Gang of Four]提出了远程外观[/b]的概念，就是一个粗粒度的外观。所有细粒度对象都没有远程接口，并且远程外观不包含领域逻辑。远程外观所要完成的工作就是把细粒度的方法转换到低层的细粒度的方法上。如果对应到微软Duwamish的例子，就是BusinessSystem层，或者叫做BusinessFascade层。

远程外观的设计都是基于特定客户的需要，大部分的需要都是希望通过用户界面来观看和更新信息。外观的设计目的[/b]就是要使外部用户的使用简单化，而不是为了简化内部的逻辑。

远程外观有有状态[/b]和无状态[/b]之分。无状态的远程外观可以组成池，这样就可以提高资源的利用率和效率，尤其是在B2C的情况下。当使用有状态的远程外观时，远程外观必须维持每个状态，这可以通过使用客户端会话状态，数据库会话状态或者服务器会话状态来完成。如果使用服务器会话状态，可能导致性能问题，尤其是在有成千上万的用户同时访问时。

远程外观带来的2个好处：

1、可以增加安全检查

2、提供事务控制。

对于远程外观，最大的错误[/b]就是把领域逻辑放在其中，“远程外观没有任何领域逻辑”