Model则是业务提供者，决定了软件提供的功能，其内部可能是一些普通的类或者是实现了某些接口的类，在这一块当中可能根据业务的不同而色彩缤纷，对于复杂的软件可能会分成很多层，如业务逻辑层、业务提供层、系统提供层、数据提供层、数据访问层等。

  我经常用于比喻MVC的例子是小时候玩的那种卡带式游戏机，Control是主机，一般来说我买一个主机就行了，只要他不坏，他就能一直让我玩这一类的游戏。View则是电视机和游戏手柄，电视机可以独立工作，他不管输入的是电视信号、影碟机信号还是游戏机信号，他只管显示，而且他决定了我们看到的效果是怎么样的，如果我想要个尺寸更大的或者彩色的显示效果，我只需要买个相应的电视机就行了，手柄也是可以换的，要遥杆还是带震动的。Model则是游戏卡带，他绝定了我玩的是什么游戏，是魂斗罗还是超级玛莉，而且游戏机主机和电视机生产厂家永远也不知道在上面有可能会运行什么样的游戏。卡带中可能会有游戏代码和存储单元，都根据游戏的需要而设计。

  有朋友提到游戏主机提供的卡带插槽的接口，在设计中，有时也由Control提供一组接口，以用于Model或View的实现，这样就形成了依赖。一般来说这样设计也没有太大的问题，只是会提高模块间的耦合度，也会带来一些侵入性。为了更完美，可以不用接口来提供契约，可以用配置信息（或称元数据信息）+反射来提供契约，那么这个类接口就可以退化到只要符合CLS就可以了，也就是普通的类，就像现在的计算机接口广泛采用USB，无论是U盘、打印机、扫描仪或者是加密狗，他们都是普通的USB设备而已。

  提到USB有一个题外话，模块的可插拔性设计甚至是热插拔设计，系统可以在不停止运行的情况下动态的挂载或移除模块，动态挂载模块需要系统能够自动发现新模块并根据自描述的信息进行自动配置，移除可能情况更复杂一点，需要“安全删除硬件”类似的功能。

  在设计广泛重用的框架时会考虑多种情况以达到更大的适应性，一般项目中应用MVC模式可以较为随意。