序言

时隔一年，弦哥重出江湖，对于我们学习.NET MVC那将有大大的好处，期待弦哥的重构系列。在弦哥与jerrychou的交流中提到了一篇文章http://lostechies.com/jimmybogard/2009/12/09/organizing-asp-net-mvc-solutions/  之前大概看过，稀里糊涂也没咋认真看，其实是英文实在不咋地，这次认真看了看把这篇文章翻译了一下，希望能给大家带来帮助。

LET'S GO (原文链接)

最近，在Twitter上提出了一个问题，在ASP.NET MVC项目中，你最喜欢的项目结构或者如何组织你的解决方案？在我周围就有很不同的策略来组织项目结构，我目前确定了一个能带给我很大灵活性的解决方案。它非常简洁：

仅此而已，两个项目。那么在每个项目中都有哪些东西呢？我们先看看UI层。我们的UI只包含网站的内容，并不包含任何代码。我只的是没有任何逻辑。指的是：

1)       没有Controllers

2)       没有Models

3)       没有Global.asax

4)       No code at all

为什么没有代码呢？因为当UI只包含用户界面的内容时，我的UI层现在匹配了配置架构。它包含了：

1）  Views

2）  CSS

3）  Images

4）  Global.asax

5）  Web.config

6）  引用Core项目

自从我的UI层匹配了我的配置架构，那就很容易搞清楚配置是如何工作的。把controllers,models等等这些混在一起，很难决定哪些该被配置哪些不需要。然后我们可以将其分成两个部门：代码和内容。

那么代码放在哪呢？我们放到另外一个项目。我们叫他“Core”层，即核心层，但是它里面可以放任何东西。所有的代码将在一个项目中，它包括我们的持久模型，视图模型，控制器，存储，定义ORM映射，任何东西。

组织代码

至于组织代码---我喜欢让事情简单。如果可以选择的话，UI根本就不需要编译，它纯粹就是一个文件夹，包含内容。它的bin文件夹里只包含core类库项目的输出文件。

另外，我使用文件夹来组织代码。用projects来组织也没问题，但是这样就太死板并且很容易把你局限在项目层次和结构中很难去改变。用我原来的项目架构，在大项目中犯了一些小错误导致被影响，并且发现这种方法没有按照一定比例。我甚至碰到过一个团队在解决方案中有100多个项目，仅有一半的项目被之际部署。别忘了，编译期在很大程度上是处理项目中的函数。一个项目中的1000个文件的编译速度远远要快于10个项目的100文件。至少我见过快一个数量级的情况。

我碰到的另一个问题是如果你被锁定在一个项目架构中就很难重新组织代码。此外仅仅是Ctrl+F5 ，如果你想将一个文件移动到另外一个项目，那么你还要考虑源代码控制历史日志，这点是令人相当沮丧的。在最近一次重新组织代码的经验中，我们基本上失去了整个历史日志。因为我们在重新组织代码时不能使用一些基本的源码控制命令。这样加重的原因在于我们使用源码控制系统如TFS时，由于实际项目文件中嵌入了源码控制信息导致。在我们的案例中，我们必须删除所有的项目并手动重新创建。相比项目和依赖来说移动文件夹是更容易的。如果您想要重新组织代码这点必须要注意。

如果你在代码库分层上有疑问那么建项目是最好的解决办法。它能很好的强制你引用依赖，迫使你遵守一些基本的规则。然而，在你开始创建“Common”类库项目，“Configuration”项目和“Mappings”项目等等项目时，一旦你领悟到这点，你就会考虑将他们移植到一个项目中。持续坚持下来的话，在日常工作中会产生代码冲突，从这点上看这样做似乎是不值得的。

那么为啥不只创建一个UI项目呢？将所有的代码放进去，你将获得绝对的速度和很大的灵活性体验。内容架构与组织代码具有完全不同的关注点。不管你打算如何组织你的代码，确保你的代码与UI分开并不要将代码和内容混合在一起。【end】

希望本文能给您带来帮助。