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

Question

我总是遇到这样一个问题，即我在 Visual Studio (2008) 中的项目变成了巨大的庞然大物，并且通常将所有内容都放入 Web 应用程序项目中。通过查看一些开源资料，我知道他们往往在一个解决方案中包含多个项目，每个项目都有自己的职责。

有人对如何重构这个有任何建议吗？什么应该在一个单独的项目中而不是 Web 项目的一部分？您能否指出有关该主题的任何参考资料，或者这只是您随着时间的推移而习惯的东西？

Answer 1

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

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

Answer 2

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

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

Answer 3

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

他们提出的基本分层是

• 一个核心项目，用于您的域对象和用于访问外部服务（包括持久性）的接口。
• 一个数据项目，它依赖于核心并实现了所有用于访问持久性的接口
• 一个应用程序服务项目，用于支持应用程序级别的问题，例如日志记录或登录验证。这仅引用核心。
• 一个只包含视图的网络项目。
• 一个 controllers 项目，其中包含您的引导代码和用于协调您的 Web 层、域的代码。

对于 asp.net 应用程序，我喜欢使用 mvp 模式，这基本上意味着

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

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