C#中的PartialClasses在webforms/winforms生成代码的场景之外有没有partialclasses的好用？还是基本支持这个功能？它部分用于支持生成的代码与程序员代码（WebForms、WinForms、LINQ-to-SQL等）混合的场景。使用它的理由更多。例如，如果您在一个大而笨重的文件中有大型类，但这些类具有逻辑上相关的方法组，您可以选择使用分部类以使文件大小更易于管理。代码生成是某些类背后的驱动力。需要的是有一个不断变化的代码生成类，但允许开发人员提供自定义代码作为类的一部分，不会被覆盖以强制在每次进行更改时重新生成类。以WinForms或Typed-DataSet（或任何设计器）为例。每次对设计器进行更改时，它都会将相应的代码序列化到一个文件中。假设您需要提供一些生成器不知道的额外方法。如果将此添加到生成的文件中，则更改将在下一次构建时丢失。我正在从事的项目对所有DAL、BLL和业务实体使用代码生成。然而，生成器只获得了75%的信息。其余部分必须手动编码（例如自定义业务逻辑）。我可以假设每个BLL类都有一个SelectAll方法，因此很容易生成。但是我的客户端BLL还需要一个SelectAllByLocation方法。我不能把它放在我的生成器中，因为它不是所有BLL类都通用的。因此，我将所有类生成为部分类，并在单独的文件中定义自定义方法。现在，当我的结构发生变化时，或者如果出于某种原因我需要重新生成BLL，我的自定义代码将不会被删除。我使用分部类来分隔我编写的自定义控件的不同子元素。此外，当与实体创建软件一起使用时，它允许LLBLGen等产品创建类的生成版本，以及自定义用户编辑的版本，如果需要重新生成实体，则不会替换这些版本。我经常使用部分类来为每个嵌套类提供自己的文件。我开发了一些架构，其中大多数实现只需要一个类，因此我们将这些类嵌套在一个类中。通过使用部分类功能并将每个文件拆分为自己的文件，使文件更易于维护是有意义的。我们还使用它们对股票进行分组以覆盖或隐藏一组股票。像这样的东西。这是混合库存更改的简单方法（只需复制文件并将部分类名称更改为目标类-当然，只要目标类也是部分类）。部分类的另一种可能用途是利用部分方法，使用条件编译使方法有选择地消失——这对于调试模式诊断代码或专门的单元测试场景很有用。您可以像抽象方法一样声明部分方法，然后在其他部分类中，当您键入关键字“partial”时，您可以利用Intellisense创建该方法的实现。如果你用条件构建语句包围一个部分，那么你可以很容易地只剪掉调试或测试代码。在下面的示例中，在DEBUG模式下，调用了LogSomethingDebugOnly方法，但在发布版本中，该方法就像根本不存在一样-这是一种无需大量分叉即可使诊断代码远离生产代码的好方法。多个条件编译块。//主要部分publicpartialclassClass1{privatepartialvoidLogSomethingDebugOnly();publicvoidSomeMethod(){LogSomethingDebugOnly();//做真正的工作}}//调试部分-可能在不同的文件中使用部分类来扩展设计器生成的代码。我认为您通常会发现设计人员创建使用这种部分类模式的代码。我发现一些课程非常有帮助。通常它们用于扩展自动生成的类。我在一个进行大量单元测试的项目中使用它们。我的UT类具有复杂的依赖关系，将多个类之间的代码分开并不是很实际。当然使用继承组合更好，但在某些情况下部分类会有所帮助。如前所述，我也认为这是一种代码味道。如果一个类太大，需要拆分成更多的文件，就说明它违反了单一职责原则，做的事情太多了。大类可以分解成一起工作的小类。如果您必须使用部分类或区域来组织您的代码，请考虑它们是否应该在它们自己的类中。它提高了可读性，您可以获得更多的代码重用。也许为时已晚，但请允许我加上我的2美分：*。在处理大型项目时，将类分布在单独的文件中允许多个程序员同时处理它。*。您可以轻松地编写由VS.NET生成的类（用于扩展功能）。这将允许您编写所需的代码，而不会弄乱系统生成的代码我在哪里我们有一个程序可以处理来自客户端的传入文件。它的设置使每个客户的代码都在自己的类库项目中，该项目知道如何处理客户选择使用的任何格式。主要代码通过定义库中的类必须实现的相当广泛的接口来使用库（可能应该是一些不同的接口，但现在改变它为时已晚）。有时候，同一个类中涉及的代码，比我们平时想象的还要谨慎。部分类允许我们将它们分解一下。在相对复杂的用户控件上，我将事件处理内容放在一个文件中，将绘图和属性放在另一个文件中。部分类对此很有用，类的这些部分通常是相对独立的，能够并排编辑绘图和事件处理真是太好了。几年前我参与了一个项目，其中有一个类型化的DataSet类，其中包含大量代码：DataTable中的方法、TableAdapter中的方法、TableAdapter实例的声明，应有尽有。这是项目的一个重要的中心点，每个人都必须不断地工作，并且对于部分分类的代码文件存在很多源代码控制争用。因此，我将代码文件拆分为修复文件或六部分类文件，按功能分组，这样我们就可以处理更小的部分，而无需在每次需要更改某些小内容时锁定整个文件。（当然，我们也可以通过不使用专用的锁定源代码控制系统来解决问题，但那是另一个问题。）总的来说，我认为这是一种代码味道。如果你的类很复杂，它可能会被分解成更小的可重用组件。或者这意味着任何继承层次都不应该有。对于代码生成场景，这很好，但我认为代码生成是另一种代码味道。我迟到了……但只是我的2美分……一种用途可能是将现有遗留代码库中的现有上帝类重构为多个类。如果对包含部分类的文件名使用适当的命名约定，它可以提高代码的可发现性。这也可以在一定程度上减少源代码存储库——解析和合并。理想情况下，上帝类应该被分解成多个更小的类——每个类都有一个单一的职责。有时执行大中型重构可能具有破坏性。在这种情况下，一些课程可以提供临时缓解。正如Matt指出的那样，修正的两边都需要在同一个组件中。我的错。我在数据访问层使用它。生成的类查询部分，如映射器。如果我需要添加映射器方法来执行未生成的花式加载，我将其添加到自定义类中。最后，在业务层中使用数据层的程序员只会看到一个具有他或她需要的功能的类。如果数据源发生变化，可以轻松生成通用部分，而无需覆盖自定义内容。我刚刚发现了部分类的使用。我有一个[DataContract]类用于将数据传递给客户端。我希望客户端能够以特定方式显示类（文本输出）。所以我创建了一个部分类并覆盖了ToString方法。有时您可能会发现非常旧的代码在工作，这使得在不破坏现有代码的情况下几乎不可能重构为不同的元素。如果没有选择或时间来创建更现实的架构，部分类可以很容易地在需要的地方分离逻辑。这允许现有代码继续使用相同的架构，同时您更接近更具体的架构。您之前使用过#region部分的任何地方可能更适合作为部分类中的单独文件。我个人对大型类使用部分类，静态成员在一个文件中，实例成员在另一个文件中。编辑：VisualStudio的DSL工具使用部分类。因此，它是许多自动生成的代码使用的功能。而不是使用#region，自动生成的代码到一个文件，用户代码（又名自定义代码）到另一个文件，甚至在不同的目录，这样开发人员就不用担心那么多废话文件了很困惑。很高兴有这个选项，您可以组合-但不强制-继承此外，将某些类的逻辑分离到多个目录中也很方便。当然对于机器来说是一样的，但是它增强了用户的可读性体验。以上就是C#学习教程：C#部分类分享的全部内容。如果对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权请点击右侧联系管理员删除。如需转载请注明出处：
