在Visual Studio中，使用c＃项目，而不是将包含多个方法和属性的类放在一个文件中，使用部分关键字和嵌套文件链接的多个文件会有任何缺点吗？
例如，如果我有一个名为Customer的类，它有一些属性和两个方法：GetOrders和GetAddress。而不是创建一个名为Customer.cs的文件并将属性和两个方法的所有代码放在该文件中，我将创建一个Customer.cs并仅将属性放在该文件中。我会把这个班级标记为部分。然后，我将在名为Customer_GetOrders.cs和Customer_GetAddress.cs的新文件中创建每个方法，每个文件都包含标记为partial的Customer类，并且只包含该方法的代码。在Visual Studio中，我将Customer_GetOrders.cs和Customer_GetAddress.cs文件嵌套在Customer.cs文件下。
我可以看到的优点是文件中的代码较少，因此不会在大文件中上下滚动，而只会看到处理您正在处理的方法的代码。此外，如果您使用源代码控制合并将更容易，因为您只需要处理每个方法中的代码。由于方法受物理文件约束，因此您可以通过查看文件的更改历史记录轻松查看方法的更改历史记录。
我能看到的缺点是有很多小文件，但我认为不会那么糟糕。这种思路还有其他缺点吗？
谢谢，
谢
答案 0 :(得分：1)
我可以看到的优点是文件中的代码较少，因此不会在大文件中上下滚动，而只会看到处理您正在处理的方法的代码。此外，如果您使用源代码控制合并将更容易，因为您只需要处理每个方法中的代码。由于方法受物理文件约束，您可以通过查看文件的更改历史记录轻松查看方法的更改历史记录。
在我看来，所有这些好处只是＆＃34;上行＆＃34;如果班级太大了如果您的班级遵守Single Responsibility Principle，则该文件永远不会超过＆＃34;太大＆＃34;管理。
此外，大多数IDE（例如Visual Studio）已经提供了大量功能来快速导航文件（例如直接跳转到成员的下拉菜单）。
我可以看到的缺点是有很多小文件，但我不认为那会很糟糕。这种思路还有其他缺点吗？
您需要在多个文件中拆分您的类型，这使得它的可维护性更低，更难以遵循，因为该类型使用的数据不再靠近使用它的方法。
您还需要为重构添加额外的维护成本，因为方法重命名，例如，现在需要额外的工作（文件重命名），这将破坏您的历史记录＆＃34;该文件中该方法的内容。
总的来说，我发现这是一种不好的做法。如果你已经生成了代码，并希望能够将其他逻辑添加到生成的代码文件中，那么部分类很棒，但除此之外，它们往往是我个人避免的。
答案 1 :(得分：1)
这对我来说是一个代码嗅觉：一个足够大的类，通过划分成多个部分来理解某些东西，这表明它有太多的责任。它可能是一个经过深思熟虑的抽象，应该被划分为多个类。
例如，如果我有一个名为Customer的类，它有一些属性和两个方法：GetOrders和GetAddress。而不是创建一个名为Customer.cs的文件并将属性和两个方法的所有代码放在该文件中，我将创建一个Customer.cs并仅将属性放在该文件中。我会把这个班级标记为部分。然后，我将在名为Customer_GetOrders.cs和Customer_GetAddress.cs的新文件中创建每个方法，每个文件都包含标记为partial的Customer类，并且只包含该方法的代码。在Visual Studio中，我将Customer_GetOrders.cs和Customer_GetAddress.cs文件嵌套在Customer.cs文件下。
从建模角度来看，GetAddress()和GetOrders()不应该是方法，至少不应该是Customer对象上的方法。 Customer可能有一个或多个Address 属性和单个，类似于集合的属性，Orders，代表客户的订单历史。
我认为你的抽象缺少一些类。也许你需要OrderFactory，给定Customer（以及可能的其他标准），知道如何找到一个或多个客户的订单。
答案 2 :(得分：0)
Visual Studio实际上存在一个大问题。您拥有的文件越多，编译甚至加载解决方案所花费的时间就越长。给它一个时间来处理大量的文本文件，想象一下每类7或8个额外的文件，一个标准的解决方案很快就会爆炸式增长。
从.net编译器的角度来看，这没有错。
唯一的另一个问题是可维护性，即代码导航知道哪里去了。