如何在Visual Studio中重构大型项目

Question

我总是遇到一个问题，即我在Visual Studio（2008）中的项目变成巨大的怪物，一切都被抛入Web应用程序项目。我知道从一些开源软件中可以看出，他们在解决方案中往往有多个项目，每个项目都有自己的职责。

有没有人对如何重构这个有任何建议？单独的项目与网络项目的一部分应该是什么？你能指点我这个主题的参考资料，还是只是随着时间的推移习惯了？

Answer 1

将项目干净地整理到命名空间中。命名空间不应该太大，也不能太小。使每个命名空间具有公共“接口”（即一组公共类），并且不从其他命名空间访问命名空间的内部实现细节。不同的命名空间通常涉及应用程序的不同部分，例如，你将拥有与UI，业务逻辑，帮助器功能等相关的名称空间。Framework Design Guidelines对如何设计名称空间有一些很好的建议。

当您认为项目变得过大时，只需确定明确相互关联的命名空间集，并将它们移动到单独的项目中。由于其他名称空间已经只使用移动的名称空间的公共接口，因此将名称空间重构为新项目仅仅是文件移动操作。

Answer 2

从下到上（你最简单的类，不依赖于框架之外的任何其他类），看看你是否可以将依赖关系分离为功能单元。例如，如果您有一堆数据或业务逻辑类相互引用，但从不引用任何UI类，那么您就有了分离到另一个项目的候选者。如果你找不到明确的分离点，那么你就有设计问题，应该做一些重构。

我也同意使用命名空间是一个很好的起点。即使在项目中，您也可以通过自然地将类组合在一起的方式来隔离或最小化依赖关系。将它们放在同一个文件夹中会强化这个分组作为一个功能单元，并且可能真正帮助那些将来必须维护代码的穷人。相信我，我试着想想那个可怜的家伙，因为不止一次，那个可怜的家伙就是我。编写代码的人在编写代码时与我的名字相同，这是一个小小的安慰。

Answer 3

查看guidance given by the Sharp Architecture project。它的ASP.Net MVC但同样的原则适用于ASP.NET和其他项目。将这些东西组合在一起的人聪明我通常会将他们的建议作为默认值，只有在我有充分理由时才会流浪。

他们提出的基本分层是

• 用于访问外部服务（包括持久性）的域对象和接口的核心项目。
• 数据项目依赖于核心并实现所有用于访问持久性的接口
• 应用程序服务项目，用于支持应用程序级别的问题，例如日志记录或登录验证。这只是引用核心。
• 仅包含观看次数的网络项目。
• 控制器项目，其中包含您的自举代码和用于协调您的网络层，域的代码。

在asp.net应用程序的情况下，我喜欢使用mvp模式，这基本上意味着

• Web 项目包含您的WebForms和代码隐藏，其中只包含重定向到演示者所需的最少代码量。您可能还需要将引导代码放在那里。这是由于ASP.Net限制，你不应该从你的代码隐藏中引用任何东西。
• 控制器项目由演示者项目替换。这里最大的区别在于，演示者必须以某种方式由WebForm实例化，而不是相反。

您还可以尝试查看ASP.NET MVP project。