几年前，我被告知在单独的 .cs 文件中实现业务逻辑代码，尽管这些文件包含相同的部分类。因此，可以像这样从业务层调用一种方法：
using(FooPartialDisposableClass partialClassInstance = new FooPartialDisposableClass ())
partialClassInstance.BusinessMethod();
行。所以现在，我只是在使用 Facade 模式时做同样的事情。这个解决方案似乎是一种更好的方法，即使您必须编写更多代码并且它的可维护性较差。
好吧，那么我的问题是……遵循部分类方法是否正确？
PS：我还考虑过接口和依赖注入来将这一层与将使用这些业务逻辑方法的层分离，但考虑到这里的工作方式，这是一个禁忌：S
Partial classes不是OOP设计功能。它们只是“代码布局”的东西，不能替代任何代码设计。
如果您愿意，它只是代码布局/分发功能。
Facadedesign 与 不同DI，如果您认为该Facade模式最适合您的项目需求，请继续。
使用部分类以防类的文件变得太大，或者您有不同的团队成员可能想要对它的不同部分进行更改Facade。在这种情况下，在不同文件之间分配文件（基于团队中的职责分配），以便更轻松地管理代码并尽可能避免冲突。
我发现将代码与部分代码分开的两个原因。
因此，两个（或更多）开发人员在代码签入期间不会遇到彼此。冲突解决来袭！
生成的代码。我将代码生成到主要部分类中，然后为自定义重载创建另一个部分。完美运行！
我相信将业务逻辑和数据层分离到单独的类中，并且我主要在这些层中使用静态方法。我真的不明白它怎么可能有更多的代码和更少的可维护性。
我会说让自己远离部分课程。如果您的课程更大，则意味着该课程中发生的事情太多了。意味着这个类违反了单一职责原则，难以维护和理解。始终尝试在一个类中关注一个问题，并在单独的类中提取其他职责，并使用 DI 模式将依赖项注入到高级类中。
这给了你很多好处，比如；1. 可以单独测试小班。2. 较小的类易于维护。3. 易于扩展。4. 与大脂肪类相比，引入新错误的机会更少。5. 易于理解等等。