I would like to use DRY beans on my client-server application (DRY: Dont Repeat Yourself). It is not a problem to me if it is highly coupled: I know that my DTO will have the same form as the database beans (Entity class in JPA). The DTO have the advantage to loose coupling between application, but if they are copied from database model there is a first duplication, and then on my screen, I use specific beans (javaFX bean) so the screen can't use directly a DTO, so there is a second duplication . The problem is in Java, but the same dependencies problem with different dependecies between client and server could appear in every language.

Here is the detail of my situation: - Backend Spring with hibernate dependencies - HTTP communication with JSON - Frontend javafx with Observable object dependencies

The purpose of my archictecture is for each database request serialize a model bean from a database, and on client side deserialize a screen bean, using JSON as intermediate format.

I want to use a common dependency between my client and server, in this common project I want to define a common objet to define the Jackson format between client and server, and I have many options:

  1. use DTO: then I copy data from Entity object from database with the same structure, then I copy this data to a javaFX Bean with the same attibutes again, but which is observable. There will be 3 classes representing the same entity

    • model -> DTO copy on backend
    • DTO transfered on HTTP
    • DTO -> Screen copy on frontend
  2. Serialize the model bean and deserialize de screen bean by ensuring the both bean can be serilized in the same JSON format using only junit test.

    • model on backend with no transformation
    • model transfered on HTTP
    • model -> Screen deserialized on frontend, JSON structure compatibility not guaranted
  3. Do like in 2. but use a common interface to be implemented by both model bean and screen bean. But all beans must implement an interface, not only the root object of the JSON, so there is structure duplication (all classes duplicated to interfaces)

    • model on backend with no transformation
    • model transfered on HTTP
    • model -> Screen deserialized on frontend, JSON structure garanted with interface
  4. Use model bean as DTO: but the client will hava a JPA useless dependency

    • model on backend with no transformation
    • model transfered on HTTP
    • model -> Screen copied on frontend, dependecies on model imply dependencies on JPA annotations
  5. Use screen bean as DTO: but the server will hava javafx dependencies, which could be missing from JDK in future release (post java 11)

    • model->Screen bean copied on backend with dependencies to javaFX observables
    • screen bean transfered on HTTP
    • screen bean deserialized on frotnedn, no transformation.

To respect the POLA principle, I would do the classical "1." with DTO, but it is not really DRY.

Here is my questions:

  • Is DTO the most expected solution for future developpers? (I want maintainability for my solution)?
  • Is it admittable to have a useless dependency to share the same objects: entity or screen beans?
  • Can we rely on JSON to transform an object to another one? Or should I have a common projet library between my client and my server?
  • It's this degree of hand wringing that leads me to wonder why people use these overblown Java architectures in the first place. – Robert Harvey Mar 16 '18 at 15:10
  • @RobertHarvey It's my architecture that is owerblown or Java? There is a better solution in C#? – pdem Mar 16 '18 at 15:15
  • 1
    Can you guarantee that your screens will always mirror your database structure? If not, then it is just a coincidence that the model, DTO and screen bean look so similar and it is not a violation of DRY. – Bart van Ingen Schenau Mar 16 '18 at 15:51
  • 1
    Unfortunately things have historically been evolving the way we sort of bound to use DTOs. Yet you can greatly simplify that task by using object mappers. For example, mapstruct.org. – yegodm Mar 16 '18 at 20:54
  • 1
    Unfortunately with the current technology stack it is almost impossible to avoid using of DTOs. So using a mapper library seems to be the best choice. I could have described what the ideal approach would be, yet, it would be far from a single project scope, and unlikely to be compatible with known frameworks. – yegodm Mar 19 '18 at 13:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.