F
Firephoenix
Gast
Hi,
für dieses Jahr habe ich mir unter anderem den Einstieg in Spring vorgenommen (so lange Stacktraces hatte ich lange nicht mehr, bis die Konsole endlich mal brauchbares ausgespuckt hatte 😳).
Ich arbeite im Moment an einer kleineren Anwendung bei der der Code mittlerweile relativ zugesetzt mit Logging-Statements ist (und ich in fast jeder Klasse damit dependencies zu einem logging-framework habe) und an einigen Stellen baue ich relativ komplexe Observer-Strukturen auf und wieder ab, was im Moment per Builder-Pattern gelöst ist.
Ich habe mal ein kleines Experiment mit Spring aufgesetzt und mal die Mischung as DI und AOP versucht, der resultierende Code war sauberer, ich musste allerdings extra Logging-Klassen erstellen und als Aspekte wieder an die zu loggenden Classen binden und alles was ich loggen wollte in die xml reinfummeln.
Damit kriege ich entweder eine zusätzliche Logging-Klasse pro Klasse oder ich strukturiere mehrere Klassen (z.b. pro package) an einen Logging-Aspekt, kostet allerdings viel xml-schreibaufwand.
Ähnlich sah das mit DI aus, aus 50 Zeilen Builder mit Abhängigkeiten zu sehr vielen Klassen wurde eine Zeile mit einer Abhängigkeit zu Spring, die Deklaration ging ebenfalls in eine xml als bean.
Wie würdet ihr in diesem Fall den Tradeoff sehen?
-Lohnt es sich auf Spring AOP (mir reichen aspekte gegen Interfaces aus) zu setzen um seinen Code von logging-statements zu befreien? (Und später evtl noch Erweiterungen wie dynamische Statistikerfassung etc einzubauen ohne den Code zu ändern?)
-Macht es Sinn die zusätzliche Konfigurationszeit in xml-Dateien zu stecken um sich die händische Verschaltung von Objekten zu sparen (mit einem bean-scope "prototype" kann man spring ja offenbar als factory benutzen).
Wäre froh über ein paar Meinungen von Leuten die schon mehr Erfahrung damit haben, mir persönlich gefällt es zwar wie "sauber" der eigentliche Domänencode nach dem ersten Einsatz von Spring ausgesehen hat, allerdings hat die xml-konfiguration doch recht abgeschreckt (und nach jedem tippfehler folgte ein wald aus exceptions...), außerdem schätze ich das konfigurationssystem von Spring selbst als relativ anfällig für namensänderungen beim refactoring ein, da im prinzip ja alles mit Strings hart eingegeben wird (Annotationen scheinen zwar etwas näher an reinem Java zu sein, verwenden aber an vielen Stellen ja selbst wieder Strings als Parameter die man bei Änderungen manuell nachpflegen müsste).
Gruß
für dieses Jahr habe ich mir unter anderem den Einstieg in Spring vorgenommen (so lange Stacktraces hatte ich lange nicht mehr, bis die Konsole endlich mal brauchbares ausgespuckt hatte 😳).
Ich arbeite im Moment an einer kleineren Anwendung bei der der Code mittlerweile relativ zugesetzt mit Logging-Statements ist (und ich in fast jeder Klasse damit dependencies zu einem logging-framework habe) und an einigen Stellen baue ich relativ komplexe Observer-Strukturen auf und wieder ab, was im Moment per Builder-Pattern gelöst ist.
Ich habe mal ein kleines Experiment mit Spring aufgesetzt und mal die Mischung as DI und AOP versucht, der resultierende Code war sauberer, ich musste allerdings extra Logging-Klassen erstellen und als Aspekte wieder an die zu loggenden Classen binden und alles was ich loggen wollte in die xml reinfummeln.
Damit kriege ich entweder eine zusätzliche Logging-Klasse pro Klasse oder ich strukturiere mehrere Klassen (z.b. pro package) an einen Logging-Aspekt, kostet allerdings viel xml-schreibaufwand.
Ähnlich sah das mit DI aus, aus 50 Zeilen Builder mit Abhängigkeiten zu sehr vielen Klassen wurde eine Zeile mit einer Abhängigkeit zu Spring, die Deklaration ging ebenfalls in eine xml als bean.
Wie würdet ihr in diesem Fall den Tradeoff sehen?
-Lohnt es sich auf Spring AOP (mir reichen aspekte gegen Interfaces aus) zu setzen um seinen Code von logging-statements zu befreien? (Und später evtl noch Erweiterungen wie dynamische Statistikerfassung etc einzubauen ohne den Code zu ändern?)
-Macht es Sinn die zusätzliche Konfigurationszeit in xml-Dateien zu stecken um sich die händische Verschaltung von Objekten zu sparen (mit einem bean-scope "prototype" kann man spring ja offenbar als factory benutzen).
Wäre froh über ein paar Meinungen von Leuten die schon mehr Erfahrung damit haben, mir persönlich gefällt es zwar wie "sauber" der eigentliche Domänencode nach dem ersten Einsatz von Spring ausgesehen hat, allerdings hat die xml-konfiguration doch recht abgeschreckt (und nach jedem tippfehler folgte ein wald aus exceptions...), außerdem schätze ich das konfigurationssystem von Spring selbst als relativ anfällig für namensänderungen beim refactoring ein, da im prinzip ja alles mit Strings hart eingegeben wird (Annotationen scheinen zwar etwas näher an reinem Java zu sein, verwenden aber an vielen Stellen ja selbst wieder Strings als Parameter die man bei Änderungen manuell nachpflegen müsste).
Gruß
