如何在Visual Studio中重构大型项目
我总是遇到一个问题，我在Visual Studio（2008）中的项目变成了巨大的怪物，一切都被扔进了Web应用程序项目。 我知道从一些开源软件中可以看出，他们在解决方案中往往有多个项目，每个项目都有自己的职责。
有没有人对如何重构这个有任何建议？ 单独的项目与网络项目的一部分应该是什么？ 你能指点我关于这个主题的任何参考资料，还是只是你随着时间习惯的东西？
将项目干净地组织到命名空间中。 命名空间不应该太大，也不能太小。 使每个命名空间具有公共“接口”（即一组公共类），并且不从其他命名空间访问命名空间的内部实现细节。 不同的名称空间通常涉及应用程序的不同部分，例如，您将拥有与UI，业务逻辑，帮助程序function等相关的名称空间。 框架设计指南对如何设计名称空间提供了一些很好的建议。
当您认为项目变得过大时，只需确定明确相互关联的命名空间集，并将它们移动到单独的项目中。 由于其他名称空间已经只使用移动的名称空间的公共接口，因此将名称空间重构为新项目仅仅是文件移动操作。
从下到上（您最简单的类，不依赖于框架之外的任何其他类），并查看是否可以将依赖项隔离为function单元。 例如，如果您有一堆数据或业务逻辑类相互引用，但从不引用任何UI类，那么您就有了分离到另一个项目的候选者。 如果你找不到明确的分离点，那么你就有设计问题，应该做一些重构。
我也同意使用命名空间是一个很好的起点。 即使在项目中，您也可以通过自然地将类组合在一起的方式来隔离或最小化依赖关系。 将它们放在同一个文件夹中会强化这个分组作为一个function单元，并且可能真正帮助那些将来必须维护代码的穷人。 相信我，我试着想想那个可怜的家伙，因为不止一次，那个可怜的家伙就是我。 编写代码的人在编写代码时与我的名字相同，这是一个小小的安慰。
查看Sharp Architecture项目提供的指导 。 它的ASP.Net MVC但同样的原则适用于ASP.NET和其他项目。 将这些东西组合在一起的人很聪明我通常会将他们的建议作为默认值，只有在我有充分理由时才会流浪。
他们提出的基本分层是
- 域对象和接口的核心项目，用于访问外部服务（包括持久性）。
- 一个依赖于核心并实现访问持久性的所有接口的数据项目
- 用于支持应用程序级别问题（如日志记录或登录validation）的应用程序服务项目。 这仅引用核心。
- 仅包含视图的Web项目。
- 一个控制器项目，用于保存引导代码和用于协调Web层，域的代码。
在asp.net应用程序的情况下，我喜欢使用mvp模式，这基本上意味着
- Web项目包含WebForms和代码隐藏，它们应该只包含重定向到演示者所需的最少量代码。 您可能还需要将引导代码放在那里。 这是由于ASP.Net限制，你不应该从你的代码隐藏中引用任何东西。
- 控制器项目由演示者项目取代。 这里的最大区别在于，演示者必须以某种方式由WebForm实例化而不是相反。
您还可以尝试检查ASP.NET MVP项目 。