Is using partial classes instead of Facade pattern an anti-pattern itself?

Question

A few years ago, I was told to implement the business logic code in separated .cs files, although this files wrapped the same partial class. So one could call a method from business layer like this:

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

Ok. So now, I'm doing the same thing only this time I'm using the Facade pattern. This solution seems like a better approach, even though you got to write more code and it's less maintainable.

Well, then my question is... could it be right to follow the partial classes approach?

PS: I also thought of interfaces and dependency injection to decouple this layer from the layers that are gonna use these business logic methods, but it's a no-no considering how things work around here :S

Answer 1

Partial classes are not an OOP design feature. They are just "code-layout"` stuff and can not be a substitute to any code design.

It's just code-layout/distribution, if you wish, feature.

Facade design is different from DI, and if you think that the Facade pattern fits best your project needs, continue with that.

Use partial classes in case when the file of the class becomes too big, or you have different team members that may want to make a changes on different parts of that Facade. In this case distribute a file between different files (based on responsibility destribution in your team), to make easier to manage a code and avoid conflicts as much as it possible.

Answer 2

I found two reasons to separate code with partials.

1. So two (or more) developers don't run into each other during code check-in. Conflict resolution blows!

2. Generated code. I generate code into the main partial class, then create another partial for custom overloads. Works perfectly!

I believe in separating business logic and data layers into separate classes and I mostly use static methods in these layers. I really don't see how it could be more code and less maintainable.

Answer 3

I would say keep yourself away from partial classes. If your classes are bigger that means there is too much going on in that class. Means this class is breaking single responsibility principle and is difficult to maintain and understand. Always try to have one concern in a class and extract the other responsibilities out in separate classes and inject the dependencies using DI pattern into the high level class.

This gives you so many benefits like; 1. You can separately test smaller classes. 2. Smaller classes are easy to maintain. 3. Easy to extend. 4. Less chances to introduce new bugs as compared to a big fatty class. 5. Easy to understand and many more.