【译】组织好你的Asp.Net MVC解决方案

最近，Twitter上发起了一个一个关于“你最爱的Asp.net MVC项目组织方式”,我自己研究了一些组织项目文件的方法。而我现在一直喜欢用的方式是一个几句灵活性的方式，此外，这个方式还非常简单。

如上图，整个解决方案里只有两个项目,首先让我们来看UI项目,UI项目只包含了那些和Website相关的文件并且不包含任何后台代码,这包括:

• 没有Controller
• 没有Model
• 没有Global.asa.cs
• 不包含任何后台代码

为什么不包含后台代码？因为UI项目只包含那些和UI相关的文件，而我的UI项目和部署项目相匹配，这包括

• Views
• Css
• Images
• Global.asax
• Web.Config
• 引用Core项目

因为我的UI项目和部署结构相匹配，所以弄清楚开发是怎样工作的将会变得容易.反之，将Model和Controller混合起来将会使得开发中将各部分分开变得困难。所以我的组织方法会将代码和内容这两部分分开。

我们的代码部分怎么办呢？放到另一个项目中，我喜欢称之为”Core”,当然名字你可以随便起，所有的代码文件都会放到这个项目中，包括持久层Model,View Model,Controller,repositories,ORM相关文件以及任何和后台代码相关的部分。

组织好你的代码

对于组织好的代码，我喜欢用简单的方式，如果可以的话，我宁愿不编译UI项目--这仅仅是一个用于存放内容的文件夹，而这个文件夹下的bin目录里只有来自于”Core”项目的dll。

另外，我喜欢用文件夹来组织代码。利用项目的方式组织代码是可以的，但是这种缺乏灵活性的做法会将你禁锢在很难改变的层和结构当中。我已经在大型项目中因为错误的组织代码而犯过许多错误,而最后我发现最好的做法并不是大兴土木，因为我曾经呆过的一个Team里动辄就是上百个项目，但是只有不到一半的项目被实际部署.所以要牢记，编译所需的时间很大程度上取决于你的解决方案中项目的多寡。在一个含有1000个文件的项目和100个文件放入10个项目中比较，前者所需的编译时间要大大的小于后者。至少在我见过的项目中是这样。

而另一个实际的问题是当你需要重新组织你现有的代码时，你会发现对于包含N个项目的解决方案来说，发现你被禁锢在各个不同项目的结构中会让你捶胸顿足。此外，这种方式在Ctrl+F5进行调试时，超慢的速度更会让你欲哭无泪。而这种方式在你的代码被源码管理软件管理时，更会显出不足，仅仅将一个文件从一个项目中移到另一个项目中就会让你的历史记录暴涨。在我最近的一个项目中，情况已经发展到甚至我们连一个简单的源码控制指令都无法执行从而导致我们所有的源码控制历史记录全部丢失，最后我们不得不重新手动创建整个项目。移动文件夹要比在项目中移动文件让人惬意很多…

如果你想将你的代码进行很好的组织和分层，使用项目的方式或许有些帮助，因为这强制让你遵循你自己一开始设定的规则，但是一旦你开始这样做，你设立了”Common”项目，”Configuration”项目”,”mapping”项目等,在后面的开发中最好考虑将这些代码回归到同一个项目当中.

所以，为什么不考虑将所有代码放入一个Core项目，所有UI放入一个项目，从而能给你极大的灵活性和最快的编译速度呢？无论你准备何种构架来组织你的代码，请确保不要将后台代码放入UI项目中，这样才能避免将代码和内容的关注点分离结构混为一谈。