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.