Best Practice FileHelper

Schuriko

Bekanntes Mitglied
Ich bekomme aus einer Config - Klasse aus application.properties einen Wert (Eigenschaft: upload.xml) für das xml upload Verzeichnis. Ich möchte jetzt eine Hilfsklasse mir schrieben für die Dateibehandlung. Sprich anlegen des Upload-Verzeichnisses (Eigenschaft: upload.xml) , ermitteln aller Dateien aus diesem Verzeichnis, etc. Diese Klasse wird später von verschiedenen Service Klassen benutzt. Mich würde jetzt interessieren, wie man soetwas am besten realisiert? Über @Component?
 

mrBrown

Super-Moderator
Mitarbeiter
da gibt’s vermutlich X Varianten für:
  • Einfach direkt Files
  • Dünnen, statischen Wrapper um Files
  • OO-Wrapper im Files
  • Das ganze als DAO
  • Das ganze als Repository
  • ...
Und dann je nachdem mit Service, Conponent oder was eigenem Annotieren, da ist man ziemlich frei. Hängt auch von der Nutzung ab, was sinnvoller ist.
 

Schuriko

Bekanntes Mitglied
da gibt’s vermutlich X Varianten für:
  • Einfach direkt Files
  • Dünnen, statischen Wrapper um Files
  • OO-Wrapper im Files
  • Das ganze als DAO
  • Das ganze als Repository
  • ...
Und dann je nachdem mit Service, Conponent oder was eigenem Annotieren, da ist man ziemlich frei. Hängt auch von der Nutzung ab, was sinnvoller ist.
Deshalb hier nochmal vereinfacht gefragt Best Practice @Component für Hilfsklassen?
 

mrBrown

Super-Moderator
Mitarbeiter
Best Practice lässt sich nicht immer generell benennen...

In deinem Fall könnte das Repository-Pattern passend sein, damit könntest du es einfach mal umsetzen. Es kann aber auch sein, dass es sich in deinem Fall als völlig falsch herausstellt...


Wenn überhaupt würde ich "Hilfsklasse" als Bad Practice bezeichnen ;P
 

LimDul

Top Contributor
Das wichtige ist, über die Anforderungen bewusst zu werden:

* Was braucht die Klasse als Eingabe zur Erzeugung
* Wer soll sie nutzen

Und weiter gedacht:
* Wie kann ich die Klasse testen
* Wie kann ich die Klassen testen, die sie nutzen

Den sobald man an Testbarkeit kommt, wird ein exzessiver Einsatz von @Component / @Autowired gefährlich. Weil man auf einmal um die Klasse X zu testen die Klassen A,B,C braucht und die wiederum die Klassen D,E,F - dann hat das nichts mehr mit einem Unit-Test zu tun.

Sprich an so eine Utility Klasse die auf Dateisystem-Ebene arbeitet hätte ich aus Testbarkeit Sicht die Anforderung, dass ich bei Nutzern die einfach gegen eine Dummy-Implementierung austauschen kann.
 

Neue Themen


Oben