単一責任原則-輸入業者
私はインポーターを書いています、それはデータベースからいくつかのデータをフェッチし、そのデータを適切な場所に置くべきです。
問題は、インポーター自体がそのデータをフェッチするのか、それとも（インポートする）データをインポーターに渡し、データベースのフェッチを外部で行うのかということです。
これを設計するより良い方法は何ですか？
インポーターがすべての仕事をするなら、それは知っている必要があります
データがデータベースのどこにあるか。
アプリケーションの「適切な場所」とは何ですか。
理論的には、これらの両方が互いに独立して変化する可能性があります。したがって、理論的にはSRPの違反です。
それでも、おそらくインポーターを2つのクラスに分割しないでしょう。データベーススキームは比較的安定している傾向がありますが、データを配置する場所を変更する必要があるのはなぜですか。したがって、物事を分割することは、私にとってオーバーエンジニアリングのように聞こえます。
抽象化は、実際にそれを利用する場合に非常に役立ちます。しかし、それには代償も伴います。
もちろん、いつものようにそれは特定のケースに依存し、あなたは多くの背景情報を提供しませんでした。
すでに受け入れられている回答がありますが、私は異なる意見を持っています-1つのソースメディアからのロードと別のターゲットメディアへの保存の両方が簡単ではない場合
たとえば、Excelを読み取り、データベースに保存します。
Excel Readerクラス
テーブルの行をトラバースし、正しい列のタイトルを確認し、日付/時刻の値を変換し、最後の「半分」の行を処理するExcelリーダーを作成できます。おそらく、独自のカスタマイズ可能なデータ検証と変換を使用して、定義された列のマップを渡します。
このクラスは、ユニットテストを適切に実行し、特定のインポートの使用を分離できます。
トップインポータークラス（コントローラー？）
メインのインポートクラスには、Excelリーダーフィールドがあり、値を格納する特定のインポートを実行できます。
データベースへの書き込みは別の問題になる可能性がありますが、データベースBeanは適切な挿入などすべてに拡張されると思います。
データベースのリポジトリBean
インポーター・クラスのフィールドも責任の分離の一形態であるため、注入されたリポジトリーBeanを検討できます。
結論
oneループの読み取りと書き込み、両方の側で特別な処理を行うことは望ましくありません。
また、単体テストの方がはるかに簡単で、サンプルデータを保存できます。 テスト駆動開発が可能です。
そして最後に、おそらくより単純なコードとコードの再利用が実現可能になりました。