C# 使用分部类而不是Facade模式本身就是反模式吗？

几年前，我被告知在分离的.cs文件中实现业务逻辑代码，尽管这些文件包装了相同的分部类。因此，可以从业务层调用如下方法：

using(FooPartialDisposableClass partialClassInstance = new FooPartialDisposableClass ())
partialClassInstance.BusinessMethod();

嗯。 所以现在，我在做同样的事情，只是这次我使用了门面模式。这种解决方案似乎是一种更好的方法，尽管您需要编写更多的代码，而且维护性较差

那么，我的问题是。。。采用分部类方法是否正确

---

PS：我还考虑了接口和依赖注入，以将该层与将使用这些业务逻辑方法的层分离，但考虑到这里的工作方式是不可能的：s

部分类

不是一个

OOP

设计特性。它们只是“代码布局”的东西，不能替代任何代码设计

如果您愿意，这只是代码布局/分发功能

Facade

设计不同于

DI

，如果您认为

Facade

模式最适合您的项目需要，请继续

---

如果类的文件太大，或者您有不同的团队成员可能希望对该

外观的不同部分进行更改，请使用分部类。在这种情况下，在不同的文件之间分发一个文件（基于团队中的职责分配），以便于管理代码并尽可能避免冲突。
我发现了两个将代码与部分分开的原因

因此，在代码签入期间，两个（或更多）开发人员不会碰到对方。冲突解决方案失败了

生成的代码。我在主分部类中生成代码，然后为自定义重载创建另一个分部。很好用

我相信将业务逻辑层和数据层分离为不同的类，并且我在这些层中主要使用静态方法。我真的不明白它怎么会有更多的代码和更少的可维护性。
我要说的是，远离部分类。如果你的班级更大，那就意味着这个班级有太多的事情要做。意味着该类违反了单一责任原则，难以维护和理解。始终尝试在一个类中包含一个关注点，并在单独的类中提取其他职责，并使用DI模式将依赖项注入到高级类中

这给了你很多好处，比如；
1.您可以单独测试较小的类。
2.较小的类很容易维护。
3.易于扩展。
4.与一个大胖子阶层相比，引入新bug的机会更少。
5.容易理解，还有更多
 顺便说一下，分部类是用来处理winforms/WPF等中的代码的。这绝对不是一个“模式”，更不用说一个好模式了。正如克里斯指出的，值得一提的是，分部类的主要用途是允许生成.cs文件，同时允许在用户提供的分部类中调整该类的部分，以便在每次重新生成其他部分时不会覆盖人工编写的部分。在我看来，我不认为仅仅因为一个文件“太大”就应该使用分部类。@KirkWoll：这种方式的使用是在不同的文件之间划分实现，以便于管理。它可以是WF designer的内置功能（由您指定），可以将一个大文件拆分为简单的逻辑部分，也可以将Facade类拆分为不同的部分，以允许多个开发人员在不发生冲突的情况下对其进行提交。所有这些都与易于管理代码的设计有关。这实际上是我的观点。当然，我只是断然不同意将文件拆分以隔离开发人员的编辑是一个好主意。或者因为它“太大了”。在任何一种情况下，这都会使课堂更加难以驾驭。@KirkWoll:我可能同意第二种假设，但第一种假设不同意。我们个人使用这种技术让我们的开发人员在同一个Facade类上工作。就我而言，从软件工程、产品级代码开发和长期可扩展性的角度来看，这是迄今为止最好的答案。