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