Implementieren von MVC bei Verwendung von JPA

Question

Wie ich MVC verstanden habe, sollte die Logik für das Modell auch in das Modell selbst eingehen - jedes Objekt zu einer eigenständigen Einheit machen. Dies bedeutet, dass die Methoden einer Klasse Auslöser und Ketten von Aktionen haben müssen. Zum Beispiel kann durch die Verwendung von setZipCode (zip) in einer Person-Klasse eine Aktion ausgelöst werden, bei der die Postleitzahl von einer Zip-zu-Stadt-Tabelle nachgeschlagen wird, und dann setCity (Stadt) gleichgesetzt wird.

Das alles scheint nett und alles, aber was passiert, wenn Sie einige JPA-Implementierung ins Bild nehmen? Wie ich es sehe, müssen die Setter und Getter der Klasse von jeder zusätzlichen Logik frei sein, da die JPA-Implementierung diese zum Aufbau der Objekte verwendet. Daher kann setCity nicht innerhalb von setZipCode aufgerufen werden. Wir haben es geschafft, mit diesem Projekt arbeite ich, indem ich die gesamte modellspezifische Logik auf die Controller-Ebene verschiebe. Anstatt die Person in diesem Fall direkt aufzurufen, würden wir PersonController.setAddressInfo (zip) aufrufen, die beides oder etwas Ähnliches behandelt. Vielleicht wäre eine schönere Option transiente Funktionen innerhalb der Entität selbst, die dies tut.

Also hier ist meine Frage: Habe ich etwas Grundlegendes in den Prinzipien von MVC oder JPA verpasst, oder kann MVC bei der Verwendung einer ORM-Schicht nicht vollständig implementiert werden? Wäre es besser, wenn die generischen Setter und Getter für JPA privat wären und die Klassen eine separate öffentliche, transiente API für die Entwickler hätten? (Hibernate scheint aus irgendeinem Grund nicht auf private Methoden zuzugreifen.)

Von den JPA-Implementierungen verwenden wir Hibernate im Projekt, mein Kollege hat EclipseLink in einem anderen Projekt verwendet und ich habe etwas über OpenJPA gelesen in letzter Zeit.

Answer 1

Ich habe die Erfahrung gemacht, dass Sie wahrscheinlich eine weitere Schicht zwischen den tatsächlichen JPA Domain Objects und Ihrem MVC Framework Controller hinzufügen müssen. Literatur über JPA nennt sie Data Access Objects (DAOs) Idealerweise sind die JPA Business Objects nur POJOs (Plain Old Java Objects) mit Getter und Setter, die keine Logik haben und die DAOs Operationen wie

List<Post> PostDao::searchPostsByDate(Date d); 
void PostDao::save(Post p); 

implementieren Ich arbeitete mit Architekturen, die sogar eine andere Service-Schicht über der DAO-Schicht hatten, wo DAOs spezifisch für eine Domain-Model-Entität waren und die Service-Klasse Transaction Management und die entsprechenden DAO-Methoden aufgerufen hat. Diese Dienste könnten mit mehreren DAOs interagieren, so dass die Service-Methoden bieten könnte wie

City MainService::getCityByZipCode(ZipCode zc); 

Ich persönlich denke, dass die Service-Schicht nicht zwingend ist, wenn Sie zum Beispiel verwenden Federn @Transactional Anmerkung in Ihrem DAOs und bieten geeignete Methoden wie

@Transactional 
City ZipCodeDAO::getCity(ZipCode z); 

Answer 2

Ich verwende das Modell in eine Business-Schicht zu trennen, die andere Geschäftsobjekte aufruft, steuert die Transaktionen und das ganze Zeug, und die Werte Schicht (Dünn POJOs).

Ein ORM kann gut in die Business-Schicht integriert werden, ohne das MVC-Paradigma zu durchbrechen.

Die JPA-Version funktioniert wie zuvor beschrieben.

Grüße!