Wie man richtig mit Struts ActionForms, Value-Objekte und Entitäten?
Habe ich geerbt, eine große Java-Anwendung, die verwendet Struts, Spring und Hibernate. Die Klassen und Schnittstellen, die ich täglich sind: Struts-Actions, Struts ActionForms, Value-Objekte, Service-Schnittstellen und Implementierungen, DAO-Schnittstellen und Implementierungen, und die Entitäten. Ich bin mir ziemlich deutlich auf, wie und warum die meisten, außer ich bin unsicher über die richtige Trennung der Zuständigkeiten zwischen den ActionForms, Value-Objekte und Entitäten. Ich sollte auch erwähnen, dass das Domain-Modell (z.B. alle Elemente) enthalten nicht viel (wenn überhaupt) echte business-Logik. Dies ist im wesentlichen eine CRUD-app und die meisten der wirklichen Logik in der Datenbank (igitt!). Sowieso, es gibt mehrere verschiedene Java-bezogene Probleme, die ich überlege:
1) es scheint, Es ist nicht viel Unterschied zwischen den Entitäten und Value Objects (VOs), und eine Menge code geschrieben werden muss, um Transformation in die andere, wenn Sie durch die service-Schicht in beiden Richtungen (Struts-Aktionen befassen sich nur mit VOs, DAOs befassen sich nur mit Personen). So, VOs und Personen scheinen etwas redundant. Warum haben Sie beide?
2) Wo sollte die VO<->Person-übersetzung-code gehen? Die service-Schicht, die Person, die VO?
3) VOs sind direkt in ActionForms und direkt gebunden-tags in der JSP (zB ). Ist das eine gute Praxis? Wenn nicht, was ist das passende design?
4) Es ist unklar, wie man richtig zu behandeln Fremdschlüssel-Abhängigkeiten in der Wert-Objekte. Zum Beispiel, bestimmte VOs haben ein Typ-Feld, das in der Datenbank-Terminologie stellen eine foreign key-Beziehung in eine Art Tabelle. In der Benutzeroberfläche übersetzt diese in ein dropdown-Feld, das ermöglicht dem Benutzer, wählen Sie den Typ, ODER ein label, das zeigt einfach die textuelle Darstellung der Art (je nachdem, auf welchem Bildschirm es ist). Nun, sollte der VO-eine Eigenschaft, die für die Typ-ID, die textliche Darstellung der Art, oder beide? Wer ist verantwortlich für die übersetzung zwischen den beiden, und Wann?
5) Die VOs haben ein Feld für Ihre Datenbank-ID. Ich dachte VOs nicht Identitäten haben? Was ist mit dieser?
Ich hoffe, diese Fragen sind allgemein genug, um die von allgemeinem Interesse sein. Es scheint, dass das kommen würde, die ganze Zeit in dieser Art von Architektur.
Außerdem habe ich den Verdacht, dass diese Architektur ist zu schwer für diese app, und wenn Sie haben Vorschläge für eine bessere, go ahead. Aber ich bin vor allem daran interessiert, die Antwort auf die obigen Fragen, da eine andere Architektur ist eine langfristige Umgestaltung, die kann ich nicht jetzt tun.
Du musst angemeldet sein, um einen Kommentar abzugeben.
1.
Angesichts der DAO - VO transformation; ob dies ist nützlich, hängt davon ab, wie Hibernate verwendet wird. Wenn die gesamte Web-request-Verarbeitung in einem einzigen Hibernate-session sollten Sie nicht wirklich brauchen, separater VO ist.
Aber, wenn deine DAO-Schicht öffnet eine Sitzung zum abrufen eines Objekts und schließt die Sitzung, bevor Sie fertig sind mit der DAO können Sie bekommen Probleme mit Sammlungen und Verweise auf andere Objekte. Es ist eine faire chance, dass diese träge geladen, was bedeutet, dass die Sitzung muss noch geöffnet werden, wenn der ersuchende diese Eigenschaften.
Kurz, bevor Sie starten Notwasserung diese VO ' s haben einen guten, harten Blick auf Sie Datenbank-Transaktion und session-Grenzen hinweg.
3.
Wie für die Verwendung einer VO in eine Form; wenn der VO-maps schön die JSP-ich würde sagen, warum nicht? Entweder bin ich beeindruckt, dass das Datenmodell so genau entspricht dem Prozess unterstützt, und ein bisschen misstrauisch, dass die Datenbank nicht normalisiert wurde (die möglicherweise oder möglicherweise nicht zu Problemen in der Zukunft).
Gehen wir zurück zu 1. Wenn Sie DAO verwenden, ist mit lazy loading und Sammlungen, denken Sie daran, dass die Datenbank-Sitzung muss außerdem die JSP-phase als die DAO werden Lesen Sie in dieser phase.
Den service-layer muss eine Einrichtung, um zu wissen, welche Datenbank-Objekte zu ändern, und die id ist entworfen, um genau das zu tun. Die service-Schicht wird zum abrufen der DAO aus der Datenbank und schreiben die Felder, die von der VO in das DAO, obwohl es offensichtlich nicht aktualisieren müssen Sie die id des DAO mit der id der VO 🙂
Was Sie benötigen, aus der Anfrage ist die id die foreign-key-Feld. Wie kommt es von der client-sollten Sie vielleicht, check-in die business-Logik, ob ein Objekt mit solch einer id vorhanden ist.
Je nachdem, ob die VO übernimmt die id des fremden Objekt oder für ein Objekt sollten Sie dann entweder:
legen Sie es in Ihre VO, und speichern Sie es mithilfe der service-layer
Ihre business-Schicht ist verantwortlich für die übersetzungen der service-Ebene befasst sich nur mit dem Objekt, das abrufen und speichern. Und entweder den text oder die id sind nicht Objekte, sondern Bezeichner der Objekte. Der service layer kann
bieten Suchfunktionen, aber es sollte nicht müssen Kontext-Informationen.
Und wenn ich lese Ihre Frage gleich Ihre VOs finden Sie andere Objekte in der Datenbank-id. In diesem Fall geben Sie die id. Wenn Sie eine Zeichenfolge, die vom client sollten Sie suchen Sie es in der business-Schicht (mit der service-Schicht), und stellen Sie die id des gefundenen Gegenstandes in der VO. Oder, wenn keine ID gefunden wird, kehren Sie eine anständige Fehlermeldung.
Schließen Hinweis; berühren Sie nicht die DAO-VO Sache, es sei denn, Sie wissen, was Sie tun WIRKLICH GUT. Hibernate ist ein leistungsfähiges und Komplexes Werkzeug, das verblüffend einfach zu verwenden. Sie können sehr leicht Fehler machen und Sie können sehr schwer zu finden. Und Kunden und Chefs gleichermaßen scheinen nicht zu schätzen wissen, die Einführung von bugs in Sachen, die verwendet werden, um zu arbeiten.
Übrigens; mein Konservatismus in der DAO-VO Sache kommen, von der Behebung von Problemen, die durch ähnliche Probleme in EJB2 Hibernate-übergänge. Der Teufel steckt im Detail, und zu verändern, wie Sie mit den Daten umzugehen Ebene ist ein großes refactoring, auch wenn es aussieht wie ein Stück Kuchen.
1) Keine Notwendigkeit für separate VO und Unternehmen : einige Unternehmen Mandat eine solche Struktur für Ihr Projekt. Es hätte Sinn gemacht, in einem anderen Projekt und daher war es beauftragt (ich kann nur vermuten)
2) Service-layer : es ist die Natürliche Trennung von DAO und Action-Ebene, richtig ?
3) Es tut NICHT weh aber Wert-Objekte gebunden sind, solange Sie korrekt überprüft werden bevor Sie gesendet, um DAOs
4) Die service-Ebene sollte die Verantwortung für die übersetzung zwischen den beiden. Beim laden und sparen Sie Zeit
5) wenn Sie nicht über Identitäten, wie würde dann verhindern Sie überschneidungen ?
Ich hoffe, dass diese knappe Antworten geholfen. Ich werde versuchen und zurück und geben eine längere Antwort später.
Beantworten Ihre Letzte Teil, verwenden Sie Spring MVC statt Struts. Dann können Sie einfach die gleiche Domain Objekte auf allen Ebenen - Klassen, die Bindung an form-Parameter sind auch in den Ruhezustand, und enthalten die eigentliche business-Logik.
Beispielsweise in einer app habe ich mit Spring MVC, hatte ich ein Mitglied der Klasse. Login, Registrierung, Passwort ändern und Profil Bearbeiten, alle Formen gebunden waren zu dieser Klasse. Die Klasse hatte auch ein hibernate-mapping und ein gutes Stück von business-Logik-innen (zum Beispiel für ein Soziales Netzwerk ein "Freund hinzufügen" Methode).