C＃中的部分类
在webforms / winforms生成的代码场景之外是否有很好的使用部分类？ 或者这个function基本上是支持吗？
它部分用于支持将生成的代码与程序员代码混合的场景（WebForms，WinForms，LINQ-to-SQL等）。
有更多理由使用它。 例如，如果在大型，笨拙的文件中有大类，但是类具有逻辑相关方法组，则可以选择使用部分类来使文件大小更易于管理。
代码生成是部分类的驱动力。 需要的是拥有一个不断变化的代码生成类，但允许开发人员提供自定义代码作为类的一部分，每次进行更改时都不会覆盖这些代码以强制重新生成类。
以WinForms或Typed-DataSet为例（或任何设计师）。 每次对设计器进行更改时，它都会将相应的代码序列化为文件。 假设您需要提供一些生成器不知道的其他方法。 如果将其添加到生成的文件中，则更改将在下次生成时丢失。
我正在处理的项目使用所有DAL，BLL和业务实体的代码生成。 但是，生成器只能获得75％的信息。 其余部分必须手动编码（例如自定义业务逻辑）。 我可以假设每个BLL类都有一个SelectAll方法，因此很容易生成。 但是我的客户BLL还需要一个SelectAllByLocation方法。 我不能把它放在我的生成器中，因为它不是所有BLL类的通用。 因此，我将所有类生成为部分类，然后在单独的文件中定义自定义方法。 现在，当我的结构发生变化时，或者由于某种原因我需要重新生成BLL时，我的自定义代码将不会被删除。
我使用partial类作为分离我编写的自定义控件的不同子元素的一种方法。 此外，当与实体创建软件一起使用时，它允许LLBLGen等产品创建类的生成版本，以及自定义的用户编辑版本，如果需要重新生成实体，则不会被替换。
我经常使用partial类为每个嵌套类赋予自己的文件。 我已经开发了一些架构，其中大多数实现只需要一个类，因此我们将这些类嵌套在一个类中。 通过使用部分类能力并将每个文件拆分为自己的文件，使文件更易于维护是有意义的。
我们还使用它们来分组股票覆盖或隐藏一组股票。 像这样的东西。 这是一种混合库存变化的简便方法（只需复制文件并将部分类名称更改为目标类 – 当然，只要目标类也是部分的）。
部分类的另一种可能用途是利用部分方法使方法选择性地使用条件编译消失 – 这对于调试模式诊断代码或专用unit testing场景非常有用。
您可以声明部分方法类似于抽象方法，然后在其他分部类中，当您键入关键字“partial”时，您可以利用Intellisense创建该方法的实现。
如果用条件构建语句包围一个部分，那么您可以轻松地切断仅调试或测试代码。 在下面的示例中，在DEBUG模式下，调用LogSomethingDebugOnly方法，但在发布版本中，它就像方法根本不存在 – 这是一种在没有大量分支的情况下使诊断代码远离生产代码的好方法。多个条件编译块。
// Main Part public partial class Class1 { private partial void LogSomethingDebugOnly(); public void SomeMethod() { LogSomethingDebugOnly(); // do the real work } } // Debug Part - probably in a different file public partial class Class1 { #if DEBUG private partial void LogSomethingDebugOnly() { // Do the logging or diagnostic work } #endif } LINQ to SQL充分利用了部分类来扩展设计器生成的代码。 我想你通常会发现设计师创建的代码使用了这种部分类模式。
我发现部分课程非常有帮助。 通常它们用于扩展自动生成的类。 我在一个重型unit testing的项目中使用它们。 我的UT类具有复杂的依赖关系，并且在多个类之间分离代码是不太实际的。当然最好使用inheritance\组合，但在某些情况下，部分类可以提供帮助。
如前所述，我也认为这是代码味道。
如果一个类太大而需要拆分成更多文件，则意味着它违反了单一责任原则并做了太多事情。 大class可以分解成一起合作的小class。
如果必须使用部分类或区域来组织代码，请考虑它们是否应该在自己的类中。 它提高了可读性，您可以获得更多的代码重用。
也许为时已晚，但请允许我加2美分：
*。在处理大型项目时，将类分布在单独的文件上允许多个程序员同时处理它。
*。您可以轻松编写VS.NET生成的类的代码（用于扩展function）。 这将允许您编写自己需要的代码，而不会弄乱系统生成的代码
我在哪里我们有一个程序来处理来自客户端的传入文件。 它的设置使每个客户端的代码都在它自己的类库项目中，该项目知道如何处理客户选择使用的任何格式。
主代码通过定义一个相当广泛的接口来使用库，这个接口是库中的类必须实现的（可能应该是一些不同的接口，但现在改变它已经太晚了）。 有时，在同一个类中涉及的代码比我们通常认为的谨慎。 部分类允许我们稍微分解它们。
在相对复杂的UserControl上，我将事件处理内容放在一个文件中，将绘图和属性放在另一个文件中。 部分类对此很有用，通常这个类的这些部分是相对独立的，能够并排编辑绘图和事件处理是很好的。
几年前我参与了一个项目，我们有一个类型化的DataSet类，里面有大量的代码：DataTables中的方法，TableAdapters中的方法，TableAdapter实例的声明，你可以命名它。 这是项目的一个重要中心点，每个人都必须经常工作，并且对部分类代码文件存在很多源控制争用。
因此，我将代码文件拆分为修复或六个部分类文件，按function分组，这样我们就可以处理较小的部分，而不必每次都需要更改一些小东西时锁定整个文件。
（当然，我们也可以通过不使用专用锁定源控制系统来解决问题，但这是另一个问题。）
一般来说，我认为它是一种代码味道。
如果您的类很复杂，那么它可能会分解为更小的可重用组件。
或者它意味着没有inheritance层次结构应该有一个。
对于代码生成场景，它很好，但我认为代码生成是另一种代码味道。
我在游戏中迟到了…但只是我的2美分……
一种用途可以是将现有遗留代码库中的现有神类重构为多个分类。 如果对包含部分类的文件名采用适当的命名约定，它可以提高代码的可发现性。 这也可以减少源代码存储库 – 解析和合并到一定程度。
理想情况下，上帝阶级应该分解成多个小class – 每个class级都有一个单一的责任。 有时，执行中到大型重构会造成破坏性。 在这种情况下，部分class级可以提供临时救济。
正如Matt所指出的那样，校正的两侧部分需要在同一个组件中。 我的错。
我在数据访问层使用它。 生成的类像mapper一样查询部分。 如果我需要添加一个mapper方法来做一个未生成的花式加载，我将它添加到自定义类中。
最后，在业务层中使用数据层的程序员只能看到一个具有他或她所需function的类。 如果数据源发生更改，则可以轻松生成通用部件，而无需覆盖自定义内容。
我刚刚发现了部分类的用法。 我有一个[DataContract]类用于将数据传递给客户端。 我希望客户端能够以特定的方式显示类（文本输出）。 所以我创建了一个部分类并覆盖了ToString方法。
有时您可能会发现工作中非常旧的代码，这可能使得几乎不可能在不破坏现有代码的情况下重构为不同的元素。
如果没有给出选项或时间来创建更真实的体系结构，则部分类可以非常容易地将逻辑分离到需要的位置。 这使得现有代码可以继续使用相同的体系结构，同时您可以更接近更具体的体系结构。
您之前使用过#region部分的任何地方可能更适合作为部分类中的单独文件。
我个人使用大型类的部分类，其中静态成员放在一个文件中，实例成员放在另一个文件中。
编辑：Visual Studio的DSL工具使用部分类。
因此，它是许多自动生成的代码使用的function。 而不是使用#region，自动生成的代码转到一个文件，用户代码（也称为自定义代码）转到另一个文件，甚至在不同的目录中，这样开发人员就不会对这么多无意义的文件感到困惑。
有这个你可以结合的选择是好的 – 但不能强制使用 – inheritance
此外，将几个目录中的某些类的逻辑分开也很方便。 当然，对于机器来说，它是相同的，但它增强了用户的可读性体验。