As I understood MVC, the logic of the model should also be included in the model itself - to make each object a self-preserved object. This means that class methods must have triggers and action chains. For example, using setZipCode (zip) in the Person class can trigger an action in which it looks at the zip code from the zip-to-city table, and then sets setCity (city) at the same time.
All this seems nice and all, but what happens when you accept any JPA implementation in the picture? As I see it, setters and getters of a class should be clean of all additional logic, since the JPA implementation uses them to create objects. Therefore, you cannot call setCity inside setZipCode. We went around this project I am working with by moving all the model logic to the controller level. Instead of calling Person directly, in this case we will call PersonController.setAddressInfo (zip), which handles both, or something like that. Perhaps a nicer option would be to have temporary functions inside the object itself that does this.
So, here is my question: did I miss something fundamental in the principles of MVC or JPA, or can MVC not be fully implemented when using the ORM level? Would it be better if the common setters and recipients are private to the JPA, and the classes have a separate public, transitional API intended for developers? (For some reason, Hibernate does not seem to pay attention to private methods.)
In the JPA implementation, we use Hibernate in the project, my colleague used EclipseLink in another project, and lately I read a little something about OpenJPA.
source
share