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

Question

几年前，我被告知要在单独的.cs文件中实现业务逻辑代码，尽管这些文件包含了相同的分部类。所以可以从业务层调用一个方法，如下所示：

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

确定。 所以现在，我正在做同样的事情，这次我正在使用Facade模式。这个解决方案似乎是一种更好的方法，即使你需要编写更多的代码而且它的可维护性也更低。

那么，我的问题是......按照部分类方法是否正确？

PS：我还想过接口和依赖注入将这个层与将要使用这些业务逻辑方法的层分离，但是考虑到这里的工作方式，这是一个禁忌：S

Answer 1

Partial classes不是OOP设计功能。它们只是“代码布局”的东西，不能替代任何代码设计。

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

Facade设计与DI不同，如果您认为Facade模式最适合您的项目需求，请继续。

如果类的文件变得太大，或者您有不同的团队成员可能希望对Facade的不同部分进行更改，请使用部分类。在这种情况下，在不同文件之间分配文件（基于团队中的责任分配），以便更容易管理代码并尽可能避免冲突。

Answer 2

我发现将代码与partial分开的原因有两个。

1. 因此，在代码签入期间，两个（或更多）开发人员不会相互碰到。解决冲突！

2. 生成的代码。我在主要的分类中生成代码，然后为自定义重载创建另一个部分。完美运作！

我相信将业务逻辑和数据层分成不同的类，我主要在这些层中使用静态方法。我真的不明白它是如何更多的代码和更少的可维护性。

Answer 3

我想说要远离部分课程。如果你的课程更大，那意味着课堂上的课程太多了。意味着这门课程违反单一责任原则，难以维护和理解。总是尝试在一个类中有一个问题，并在单独的类中提取其他职责，并使用DI模式将依赖关系注入高级类。

这给你很多好处，比如; 1.您可以单独测试较小的类。 2.较小的类很容易维护。 3.易于扩展。 与大脂肪类相比，引入新虫的机会较少。 5.易于理解等等。