1、沉重的网络负担
在没有SessionBean的时候，客户端直接同底层的EntityBean进行交互，形成的是一种具有紧密耦合的硬编码机制，对于远程的客户来说，还附加了沉重的网络交互负担，具体的交互图如下：
在上面的图中，我们假设客户是通过网络对EntityBean的访问，如果EntityBean中有4个字段ABCD，客户要进行字段ABCD的值的设置，就要进行4次网络的传输，我们知道，一个客户要远程与EntityBean交互，就要经过如下的操作：
这样一来，每次进行一次字段ABCD的设定，都要经过4次网络交互，网络的速度一直就是分布式的一个瓶颈，如此沉重的负担毫无疑问会成为项目的拦路虎。
期待的解决方案：如果一次把信息通过网络传输过去，4个字段的设置都在本地服务中进行，就会较少75%的网络负担。
2、严重的不一致错误
我们再看看上面的这个模型，上面的模型有时候（概率也许非常小）会导致数据的不一致，例如，我们设置了字段AB，当设置字段C的时候，网络突然中断了，怎么办？
网络中断就意味着客户虽然设置了AB，却没有办法设置CD，如果CD和AB是相关联的，例如A代表账号，B代表用户名，C代表存款余额，D代表日期，当账号和用户名都改了，本来存款和日期也应该一并修改，但是网络的中断破坏了数据的这种一致性，这无论对用户还是对银行都是一种威胁。
期待的解决方案：如果网络出现异常后，远程服务器能够进行数据的rollback，那么这种危险的不一致问题就有可能得到解决。
3、硬编码导致的高耦合
我们再回头看看上面的模型，我们会发现，如果EntityBean由于某种原因需要改动，那么客户端的代码也必须进行修改，因为客户端是对EntityBeanAPI的硬编码，同时我们也很清楚，客户的需求是多变的，这种高耦合会使我们的项目很快破产。
期待的解决方案：如果能够做到层次的分离，就如同数据库中的外模式、模式、内模式一样，那么就可以克服高耦合，提高系统的健壮性和灵活性。
当然，在实际的应用中，还可能会有这样那样的问题，但是上面的这3个问题就足以促使我们去使用Façade模式。
想要对业务逻辑解耦，必须对代码进行进一步的抽象，但是并不意味这抽象程度越高，代码逻辑就会变得复杂，也不意味着代码越来越难读。代码的复杂程度应该和业务逻辑的复杂程度有一个正比的关系。只有需求复杂度上去了，代码才应该越来越复杂。为了抽象而抽象，为了解耦而解耦是没有意义的。
设计模式是从已经完成的代码和设计中提炼的，不是在设计和编码之前构思的。
永远不要为了眼前不存在的需求引入设计模式，更不要为了美化代码而引入设计模式，这些都是过度设计最直接的根源。
引入设计模式最恰当的时机是需求变更的时候对代码的重构，而且要注意，一次重构只引入最少量的设计模式，能满足本次变更的需求即可。
设计模式主要用在沟通上。基本要求是：整个团队都要理解该模式，这样大家一看代码风格就猜到真正的逻辑代码在哪个文件哪个类哪个函数里。函数间的互相刁用逻辑也比较清楚。便于沟通。
如果仅仅是自己设计或者小团队或者长期共事的团队，我们往往都是按自己的设计方式设计，不一定完全符合设计模式描述的那样。只要便于理解、沟通，代码好维护，没有逻辑性上的设计错误。