I have a simple task this is what I need the code to do:

  1. Read data from a third party REST resource.
  2. Parse the json object to match my internal structure.
  3. Save the parsed data in my database.

I could just be lazy and have everything done in a single method, but I want to apply best practices, apply tests and have clean code, but being careful about overengineering.

My plan is to have three separated classes.

1. RestResourceReader
       List<OriginalResourceDTO> GetAll()

2. Parser
       List<ParsedResourceDTO> Parse(List<OriginalResourceDTO>)

3. ResourceRepository
       void Insert(List<ParsedResourceDTO>)

So in those three classes I have all the functionality needed. Then something must orchestrate those three classes in order to do something useful.

Should I just call those three classes inside "Main" in a console app?

Or should I create a fourth class called Syncer, where it will have a Sync method that will call all the functionality, and then just call that method inside Main?

I don't know sometimes I feel like I'm overengineering something too simple.

  • 3
    If you see how to write it as one method then write it that way. Now that you have a working method see if there is a class or two that could be extracted. Now don't you wish you'd written some tests? Sep 9, 2017 at 22:52

2 Answers 2


My rule of thumb: If you are in doubt, use the simplest of the possible solutions. That would be performing the three calls in the Main method and eschew the Syncer class unless you know you need it.

But if the Main method also contains other logic apart from these three lines - e.g. reading of configurations, parsing of command line argument and so on - then the orchestration should at least be extracted into a separate method.

  • Thanks, at least for now I think it would be enough to leave the three methods inside main, in the future I may add more functionality, I will refactor when that time comes and maybe use @Christophe solution Sep 10, 2017 at 19:29

In fact, what you describe is not just a way to access and data, but really a logical succession of steps to implement an operation that I would call "import data from a remote service" or "acquire new data".

So I'd use a fourth class according to implement Martin Fowler's transaction script pattern.

There are two ways to implement it: either with a single class encapsulating the different transaction scripts to be performed, or using a separate class for each transaction script, thus implementing the command pattern


The transaction corresponds to a higher level of abstractions. Using it, will contribute to clean code by avoiding you to mix different levels of abstractions.

If you do this transaction only once in your code, and for a single kind of ressources, this approach could of course seem over-engineered.

If you have hundreds of different kinds of resources, this approach together with some clever dependency injections, could help you to decouple the overall logic from the concrete resource types. This will allow you to reuse the same import transaction many times, which will save you an awful lot of time.

  • 1
    Thank you, I think for this particular case it would be over engineered, but I have another project where the command pattern would be really useful Sep 10, 2017 at 19:23

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.