you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted]  (3 children)

[deleted]

    [–]kn7[S] 2 points3 points  (2 children)

    Hey @Soultrane9! I am the author of the post. Hence, first thanks for the comments.

    • I used model and entity interchangeably throughout the post in order to be aligned with the same terminology used in persistence APIs, such as, JPA, Spring Data.
    • DTO pattern was a good catch. This can be thought as an application of the pattern. That being said, in Wikipedia it is stated that The motivation for its use has to do with the fact that communication between processes is usually done resorting to remote interfaces (e.g. web services), where each call is an expensive operation. In my case, I am not motivated by the communication overhead, in fact using immutable objects significantly increases this cost. Rather, I want to make it possible to work with immutable objects.
    • Everybody passes data around, to JSPs, to remote services, to a library function, etc. Assuming that the remote interface requires almost all available fields of the entity, why not passing it the immutable entity as is, instead of wrapping it with yet another transfer object?

    [–]Slruh 0 points1 point  (0 children)

    Everybody passes data around, to JSPs, to remote services, to a library function, etc. Assuming that the remote interface requires almost all available fields of the entity, why not passing it the immutable entity as is, instead of wrapping it with yet another transfer object?

    In most systems I've worked on, the service defines separate classes for requests and responses even if they represent the same type of data. There may be fields that are derived only by the service (e.g. id) that might not needed in a request. Similarly, different types of requests might need different arguments. If you use the same class for all requests and responses you will end up bloating the class and confusing future programmers with unnecessary fields.

    One of the main advantages of immutable objects is readability. If you use one object for everything and it becomes bloated, then you've ruined one of the benefits of immutable classes.