再思MVC结构应用在桌面程序中的得失

在桌面应用程序开发中，面对于不同规模的程序，应用起同一种结构的MVC，显得的有些见酌。根据MVC的概念将程序分成3个部分，界面，业务，数据模型。程序实现的核心主要集中在业务和数据的组织上，那么更具不同部分的复杂度，将有不同的结构形式，是程序在开发的便利性、程序的扩展能力、生命周期上得到最优的提升。

 

1.       业务复杂程度对程序结构的影响：

 

所谓业务的复杂是指业务算法的复杂或业务和周边业务关系的复杂。

 

当业务复杂时，程序业务必须分离成独立的模块，由于业务在ctrl中完成，势必将v和c隔离成两个独立的模块（或动态库），这就形成了m、v、c的远距离。将造成访问的间接性，不易使用。

这里的每个对象部署到一个模块或动态库中。

 

在数据组织关系复杂和业务复杂两者同时存在的情况下是有利的，业务的复杂会促使业务独立成单独模块，数据组织复杂会促使数据组织成为单独的模块，虽然增加访问的间接性，但使程序整体构建的难度分散和降低了，使实现成为可能，加上三者可以独立变化和演进增强了程序的生命期和扩展能力。

但数据组织简单的情况下这种隔离会显得笨重。此时使用model-view近距离结构性较为合适。

上图中，view直接聚合model,使用subCtrl更新model的数据。xxxCtrl负责处理了程序复杂的业务。subCtrl仅承担了更新model中的数据，数据都由xxxCtrl准备好了。

View,subCtrl,model部署在一个模块中，subCtrlCollection,ctrl,xxxCtrl部署在一个模块之中。

 

当业务简单的情况下，使业务独立成独立的模块会使程序的规模扩大。模块与模块之间是有隔离性，这种隔离性正是使用模块化带来的溢出。但业务相对简单时这种溢出相对不明显，而因隔离带来访问的间接性成为此时重舌之重。此时将业务和界面整合到一个模块能带来明显的便利。

View直接聚合xxxCtrl和model，这种结构也在一定程度上做到了业务和界面的隔离，使业务和view分别演进。View,XXXCtrl,model同时部署在一个模块之中。

 

2.       数据组织复杂型：

数据组织的复杂性是指，组成模型的数据类型的多少和数据与数据间关系的复杂性。并不指数据量的多少。

通常情况下，数据的复杂性与界面的复杂性有直接的关系，复杂数据模型程序必定有复杂界面，反之却并不依然，有复杂界面的程序并不一定有复杂的数据模型。

 

复杂的模型，必定导致大量细粒度数据对象的组织，从设计模式的角度出发，Façade是最合适的构建方式，但它并不完美，导致了与界面耦合的沟壑。相反，代理和适配却能有效解决这些问题。

这里几个关键数据模型占据了重要角色，ModelProxy,ModelRelational,ModelAdpter，这几个模型都不是存储数据的实体，ModelProxy对象从多个model中提取各自的部分数据构成了自己，最终数据的读写依然操作在了数据实体模型上。

ModelAdpter建立起了一个模型到另一个模型的关联。当源模型的某数据发生变化后对另一个模型数据产生影响时，将需要这种关联。

ModelRelational建立了双向关联，他的效果，等同于两个model使用ModelApdter彼建立了关联，但却要解决环形关联。

 

3.       界面复杂型：

由于对用户体验和界面美观的要求越来越高，界面已经变的越来越复杂，但这一部分的复杂却没有引起程序的“灾难”，因为他仅仅只出现程序的表示层（最顶层）。各种程序开发的界面库也都对其做了充分的支持。这里不再做特别讨论。

 

4.       程序的规模：

程序的规模，又可分为小程序，中型程序，和大规模程序。

大型程序实现的功能和数据的复杂度通常都比较高。为使程序保持足够的扩展性和足够强的生命力，不用考虑其余的形式，需要将m,v,c三个部分分开部署。（大多大程序都有自己的应用程序框架，并且都有多层结构）。

中等程序和小程序就需要根据上面的讨论，选择不同的部署方式