I'm writing an importer, it should fetch some data from the database and put that data into appropriate places.

Now the question is, should the importer itself fetch that data, or should that data(to import) be passed to the importer and database fetching would be done outside?

What's a better way to design this?


If the importer does the whole job, it has to know

  1. Where the data is located in the database.

  2. What the "appropriate places" in your application are.

Theoretically, both of these could change independently from each other. So theoretically it is a violation of SRP.

Still I would probably not split the importer into two classes. Database schemes tend to be relatively stable, and why should the places where you have to put the data change? Therefore splitting things up sounds like overengineering to me.

Abstraction is very helpful if you actually make use of it. But it also comes at a cost.

Of course as always it depends on the specific case and you did not provide much background information.

  • Good not answering ;) – Fabio Jan 26 at 1:18
  • It's not wrong to consider "transport data from A to B" as a single responsibility, as the transportation of data inherently means there is a source and target. The extra responsibilities start cropping up when "from A" entails non-trivial retrieval logic, which in and of itself if not related to the transportation of the data but only to its acquisition. So as long as the data acquisition can be considered trivial, there's no need to split the transportation of data into separate responsibilities. – Flater Feb 7 at 8:26

There is an already accepted answer, but I do have a different opinion - when both loading from one source medium and saving to another target medium are not trivial.

For instance take reading an Excel and storing in a database.

Excel Reader class

One can create an Excel reader with which to traverse the table rows, check the correct column titles, convert date/time values, deal with the last "half" row. Maybe pass a Map of defined columns with their own customizable data validation and conversion.

This class can nicely be unit tested and decoupled of the specific import usage.

Top Importer class (controller?)

The main importing class could have an Excel reader field and do a specific import, storing the values.

Writing to the database could be a separate concern, but I believe that the database beans will be extended to have adequate inserts and all.

The repository bean(s) of the database

One may consider the injected repository beans, as fields of the importer class are also a form of separating responsibilities.


What one would not like to have is one loop reading and writing, with special handling on both sides.

Also unit tests are much easier, one might store sample data. Test Driven Development is possible.

And finally maybe simpler code and code reuse are now feasible.

  • I tend to think of the "Importer" as the process overseer/controller and each of the steps you've laid out as the "single responsibility," like you set up here. It translates well into code in any number of languages. – Patrick Hughes Feb 7 at 19:02
  • 1
    @PatrickHughes yes, sketched was an actual piece of software and an all-in one, quite unpleasant other importer I also saw. It really separates responsibilities and at least halves the code by delegation. Though the accepted answer might be feasible for a straight-forwards CSV import. – Joop Eggen Feb 8 at 7:21

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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