Ich arbeite an der Internationalisierung von Benutzer eingegebenen Daten in einem ziemlich großen Client / Server (HTTP (Hessian) ist für die Kommunikation verwendet) Anwendung, die in einer Datenbank gespeichert ist. Benutzer können die Sprache auswählen, die sie sehen möchten, und es gibt eine Standardsprache, die verwendet wird, wenn eine Übersetzung in der gewünschten Sprache nicht vorhanden ist.
Derzeit kann eine Datenklasse wie folgt aussehen:
%Vor%Nach der Internationalisierung könnte es so aussehen:
%Vor%Natürlich kann es interessant sein, einen Delegate-Getter in MyDataClass zu erstellen, der dafür sorgt, dass der Text in der richtigen Ländereinstellung abgerufen wird:
%Vor%In meinem Team gab es jedoch Bedenken, dass das Gebietsschema ständig weitergegeben werden muss, bis sie die Datenklasse erreichen. Da all diese Dinge auf dem Server passieren und jede Anfrage an den Server in einem eigenen Thread behandelt wird, haben einige Leute vorgeschlagen, das angeforderte Gebietsschema in einem ThreadLocal-Objekt zu speichern und ein rückwärtskompatibles Argument ohne Argumente zu erstellen:
%Vor%Das ThreadLocal muss dann eine globale Variable (irgendwo statisch) sein oder es muss bei jeder einzelnen Instanzerstellung in MyDataClass eingefügt werden (wir benutzen spring, also könnten wir es injizieren, wenn wir unsere Datenklassen federverwaltet machen fühlt sich falsch an mich)).
Die Verwendung eines ThreadLocals für das Gebietsschema fühlt sich irgendwie falsch an. Ich kann vage argumentieren, dass ich die unsichtbare Magie im Getter und die Abhängigkeit von einer globalen Variablen (in einer Datenklasse!) Nicht mag. Ein "schlechtes Gefühl" zu haben, ist jedoch keine gute Möglichkeit, mit meinen Kollegen darüber zu diskutieren. Um zu helfen, brauche ich eine Antwort mit einem der folgenden:
Dieser Ansatz ist absolut gültig. Beispielsweise macht Spring Locale über ThreadLocal über RequestContextListener und LocaleContextHolder .
Wenn Sie eine benutzerdefinierte Implementierung erstellen, stellen Sie sicher, dass Sie Ihr ThreadLocal (set / remove) richtig handhaben.
Obwohl es gängige Praxis ist, möchte ich nicht "tief" innerhalb der Anwendung lokalisieren.
In diesem Zusammenhang:
%Vor%Wir machen das:
%Vor%Und dann tun, z.B. in einer JSP- oder Ausgabeschicht:
%Vor%Die Logik selbst ist sprachunabhängig. Es gibt Fälle, in denen die Anwendung nach einer Verarbeitung das Ergebnis per E-Mail sendet, sie protokolliert und dem Webbenutzer in allen verschiedenen Sprachen präsentiert. Daher muss die Verarbeitung zusammen mit der Ergebnisgenerierung und der Lokalisierung getrennt erfolgen.
Die Verwendung eines lokalen Thread, wie Sie ihn beschreiben, ist ein sehr häufiges Muster in Webanwendungen. Sehen Sie sich diese Klasse in der Spring API als Beispiel an:
%Vor%Verwenden Sie einen Servletfilter (oder einen ähnlichen Filter), um das Gebietsschema in einem lokalen Thread festzulegen, und löschen Sie dann den Gebietsschemawert, nachdem der Server jede Anforderung beendet hat. Anstatt es an jeder Stelle einzufügen, an der es verwendet wird, verwenden Sie eine statische Factory / Accessor-Methode, die RequestContextHolder ähnelt: RequestContextHolder.getRequestAttributes ().
ThreadLocal ist eine schlechte Übung. Es sind globale Variablen und es gibt viele Artikel darüber, wie schlecht das ist, in jeder Sprache. Die Tatsache, dass Spring es benutzt, rechtfertigt es nicht, es zu benutzen. Ich mag die Lösung, die cruftex gegeben hat. Vermeiden Sie die Weitergabe von Daten über globale Variablen.
Tags und Links java thread-local design