换个角度看MVC中的耦合性
在MVC模式的主动通知中有两种通知方案:
1,模型仅仅是通知视图,模型发生了改变,至于具体发生了哪些改变并没有告诉视图,需要视图在得到通知后,根据自己的兴趣点去主动查询模型中的相关数据。
2,模型在通知视图时同时携带改通知相关的数据(这些数据通常可以满足视图进行更新的需要),这些数据通常是模型从自身提取出来并通过某种方式包装起来,提供给视图,视图在得到通知的同时也得到了进行更新所必须的数据,就不用再去查询模型了。
其实第二种方式中因为模型要预先的提供通知相关数据,而这些数据通常已经足够视图使用,否则视图还是要查询模型的其它数据以满足自己的需要(而这就倾向于向第一种方案靠拢)。也就是说模型通知时所提供的数据必须具有某种程度上的完备性,而这种完备性可能和视图是相关的(至少在系统设计时要考虑视图更新时需要哪些数据),而MVC的本意是要分离模型和视图的耦合性,但是这种相关性确以一种隐式的方式(从系统详细设计阶段就开始了)引入了耦合性。也可以认为这种耦合性跟MVC所要解决的耦合性是不同的。
从这种通知数据的完备性上来看,第一种方案实际上也存在这种相同的耦合性,因为视图在得到通知后要主动查询模型中的数据,所以在设计模型的时候需要提供一种接口来暴露模型的内部数据,唯一的不同就是这种接口相比与第二种方案中的通知数据包装器来说要灵活的多。因为包装器仅仅是为了携带某一个通知所需要的数据,是为此通知单独设计的,不能用于其它地方。而第一种的接口确可以提供灵活的接口,最大限度的满足不同种类通知查询模型数据的需要。