MVVM解决方案的一般结构_.NET_编程开发_程序员俱乐部

　　解决方案的结构一般是三个解决方案文件夹，分别是：

　　Models

　　ViewModels

　　Views

当然需要的话可以扩充，如Services、UnitTest等等。

　　然后每个解决方案文件夹里面包含各自的项目，项目里面的命名空间名自动跟随项目名，而不跟随解决方案文件夹名，而且用解决方案文件夹的好处就是解决方案不提供物理管理，只提供逻辑关联，所以在项目文件夹里是找不到解决方案文件夹的；解决方案文件夹可以右键直接编译，不同于普通的物理文件夹，普通的物理文件夹只能创建在项目下面，里面不可以再添加项目文件，而且不可以右键编译，这是他们两个的区别所在。

　　Models里包含的是数据以及数据是怎么来的，包括访问数据库，xml等等，这里面都是类库，不涉及任何UI的东东。

　　Views里面包含的是所有的UI，这里面都是界面，包括字体、Style、图片、动画、窗体、用户控件等，数据要怎么展示给用户，都在这里面，并且这里面只包含“纯UI”的代码，不涉及任何处理数据的代码。Views里面的每个工程的结构一般为：

　　Fonts

　　Images

　　Styles

　　UserControls

　　Windows

　　App.xaml

　　ViewModels里包含的是所有的逻辑，Models里的数据怎么组织、处理、调用、供给界面展示，都在这一层，如我之前所说，ViewModel其实意为“Model for View”，View里的UI全部、或者部分，直接、或者间接地把它的DataContext指向这里，所以这里的数据、方法、属性、命令、事件一般是为Views里的某个UI定制的，也可以是为某“一群”UI定制，这个看具体的需要，如果很多地方用到同一个逻辑，不妨抽象出一个公用的ViewModel，如a界面的ComBox要一个部门的列表作为数据源，b界面也有一个ComBox需要同样的部门列表，c界面也需要，那就把这个逻辑抽象出来公用。

　　为何要分出这么多项目，其实源自于CS程序的软肋。CS的东东，交互用户了，很开心，出Bug了，修改，然后重新发布到用户手里，重装，这是个很费事的过程，不像BS的，完全没有这困扰。把逻辑从UI的项目里抽出来，到最后就是一堆exe和dll，只要不涉及本质性的改动，哪个出问题了改哪个，到时候直接替换。