I am currently building a C# application that gets JSON data then it calculates something then stores the results in a database, what is the proper way to design the application.

This is how it's now

  • I have a static class that gets and parses the JSON, then stores it in an object and all objects are then stored in an object list. This class has 2 public methods, 1 private method and about 200 lines of code.
  • I then have a static class that loops through the object list and calculates the results based on each objects values. This class have 2 public methods and about 200 lines of code.
  • I then have a static class that stores the results in the database. This class has 1 public method and 25 lines of code.
  • And I have the main class that calls everything. This only has the main method and line 10 lines of code.

I think that I am overusing the static classes and could replace one or a couple with simple method (in the main class) instead of having a separate static class for it, am I?

My question is not if I should use objects (non-static) classes instead of static classes, I have no way to reuse the classes so there is no reason to make it non-static. My question is if I should remove some classes and turn them into methods in the Main class.


3 Answers 3


This might be unorthodox but I don't see any issues with what you describe. From the language perspective the idea of a 'static class' doesn't really mean anything. It's simply a term for a class that cannot be instantiated. Static methods/functions (I can never remember the precise difference and every time I look it up, I decide it's not a useful distinction) are simply methods that can be called without an object reference. That is they lack a this context. You can create static methods on instantiatable classes as well. From the compiler's point of view, there's nothing different about a static method defined in a 'static class' and a static method declared in any other kind of class.

If you don't need an object, I think that is just fine and dandy. In fact, I would say I greatly prefer it over being forced to create an object for no reason.

You might be wondering when an object is a good idea. If you aren't sure, check out the replace method with method object refactoring might be a good place to start. Another good reason you might declare a method as non-static that doesn't use, reference, or need this is when you need to implement an interface.

If you don't have a good reason to move a static method to an object context, I say don't. There's no issue and I prefer method reference passing anyway.


Your design seems to use static classes as substitute for modules: the classes group related functions and (hopefully) hide internal details such as auxiliary functions and global variables.

There is nothing wrong with this modular design; it promotes encapsulation. But it constraints the use of your classes. For example:

  • several files can't be opened and parsed/processed in parallel using multithreading.
  • reusing the classes in different places is risky (e.g. a static function could be called at top level, ignoring that another static function is called in one of the auxiliary functions).
  • risk of tighter coupling (e.g.access to static variables of other static classes).

Using using object oriented approach with non-static classes could provide additional benefits. For example:

  • Increase reuse of the classes (each instance is on its own, so no issue with parallel or interleaved used).
  • interfaces could strengthen decoupling of classes and reduce risk of accidental leak of implementation details.
  • Polymorphism would allow different processing classes (the "loop" class).

Of course, if you don't need this, stick to your design. But read this article on the pros and cons of the static classes for an informed decision making.

  • several files can't be opened and parsed/processed in parallel using multithreading. -- Sure you can, unless you're forbidding yourself from using any class or collection in the Framework that is not static. Commented Oct 8, 2022 at 18:48
  • 1
    reusing the classes in different places is risky -- Only if you're holding static state, which is something you probably shouldn't be doing unless you have a good reason for doing so. You incur the same risk any time you call any method from another, whether it's a static method or not. Commented Oct 8, 2022 at 18:49
  • 2
    @RobertHarvey In the specific case where the static classes are stateless and made of only static functions the two arguments are indeed not applicable, as you rightly point out. However in the general case of a static class, i.e. when there can be a global state, they both stay relevant. Now if you need to know the internals of the class (i.e. if there is a state or not), you defeat the purpose of encapsulation, and your code becomes dependent on assumptions that constrain the evolution of that static class.
    – Christophe
    Commented Oct 8, 2022 at 19:09

There is rarely a case for using a static class or method rather than a 'normal' instantiated class.

I would have the following

  • A Model library
  • A JSON repository which encapsulates deserialization of the objects from JSON
  • A Database repository which encapsulated storing the objects to a database
  • A Service class, which brings everything together where you inject the two repositories by interface
  • An Application, which news everything up and runs the service. Maybe with a DI container

Now you can unit test all the interfaces, replace them with new implementations as required, have various applications, web, cli, mobile, which wrap the service and provide the same functionality in different mediums

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.