3

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

Painy James
  • 805
  • 2
  • 13
  • 26
  • AFAIK, partial classes were meant to handle code-behind in winforms/WPF and the like. It's definitely not a "pattern", let alone a good one. – Louis Kottmann May 30 '12 at 11:16

3 Answers3

7

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.

Michael Berkowski
  • 267,341
  • 46
  • 444
  • 390
Tigran
  • 61,654
  • 8
  • 86
  • 123
  • As Chris point out, it bears mentioning that the primary use of partial classes is to allow .cs files to be generated while simultaneously allowing parts of that class to be tweaked in a user-supplied partial class so that the human-written portion is not overwritten each time the other part is regenerated. IMO, I do not think you should use partial classes merely because a file is "too big". – Kirk Woll May 30 '12 at 14:03
  • @KirkWoll: the use in that way is devide implementation between different files for easy management. It could built-in feature of WF designer (mantioned by you), it could be intentinal done to split a big file into simple logical pieces, it could be slit Facade class into differen pieces to allow multiple dedvelopers to commit on it without running into a conflict. **All** this is related to devision for gaining easy management of the code. That is actually my point. – Tigran May 30 '12 at 14:08
  • Sure, I just categorically disagree that it's a good idea to split files up so as to isolate edits by developers. Or because it's "too big". In either case, it makes the class much more difficult to navigate. – Kirk Woll May 30 '12 at 14:25
  • @KirkWoll: I *may* agree on **second** assumption, but on first not. We personally used that technique to let our developers work on same Facade class contemporary. This is **one** of cases, where benefit overcomes the difficulty of managing it. – Tigran May 30 '12 at 14:38
4

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.

Chris Gessler
  • 22,727
  • 7
  • 57
  • 83
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.

Ashik Wani
  • 31
  • 2
  • As far as I'm concerned, this is by far the best answer, from a software engineering, production-grade code development and long-term scalability point of view. – Edouard Berthe Mar 15 '20 at 16:47