程序主界面的作用

       在桌面程序中。都会有一个主界面。从我经历的 项目来看，每个主界面都包含了大量的方法。我以前参与过的一个项目的MainForm的代码量居然有2W行。造成这个问题的原因有两个: 第一是 主界面是系统的主控制器。系统的大部分功能都在这里展现出来。大量的菜单、工具条当然需要大量的代码来构造，挂接事件。处理事件。第二个原因和VS.net有关系。一般我们都通过VS.net工具直接挂接事件。这样事件的响应方法就在主界面里面。大部分时候我们都没有很好的将业务方法和界面分离。这样主界面里的代码量庞大就是必然的了。
       除了代码量巨大以外,它还带来一些问题，首先这样大量的代码要维护其可读性是一项大的挑战。其次由于代码都对在一起，不同子系统之间的互相依赖也被强化了。
       在开发了多个项目以后，我很想改变这种做法。我想在的想法是主界面就是一个控件容器。我们把控件放置在这个Form上面就可以了。至于它要挂接的内容都在别的地方处理。
        目前我的具体做法是:
        1.在主界面中声明所有的控件 (都为 internal)
        2.在主界面中提供对系统各个部分的数据模型的访问方法
        3.对于每一组控件提供一个UI类来负责构建控件、响应事件等工作。
        4.业务方法都封装为特定的类，这些类在第三部的 UI类中的事件响应代码中完成对数据模型的更新。
  
        使用这种方法有一个很显著的问题.那就是主界面上的所有控件的访问级别至少必须是internal。有可能还需要public .在开始考虑使用这种方法的时候。觉得不应该将这些东西暴露出来。但是实际上除了UI类以外没有别人需要访问这些控件。所以这样做是可以的。如果为每个控件写一个geter/seter的，那代码量就大了。而且会显得多此一举。因为我们分解主界面的主要目的是减少主界面的代码量，提高代码的可读性、降低不同子系统之间的耦合。
     而这些UI类本身对主界面有依赖,以及关系紧密的子系统互相之间有所依赖也是可以的。