Hi,
I have some questions regarding the OSGi enRoute microservice example and the
usage of DTOs.
([enroute-tutorial-jpa](https://enroute.osgi.org/tutorial/032-tutorial_microservice-jpa.html),
[enroute-dto](https://enroute.osgi.org/FAQ/420-dtos.html)).
I think I understand the purpose of DTOs (easy to write, easy to process,
useful when data leave the system) but their usage in the JPA example is not
clear:
> Because of the de-coupling provided by the
> [DTOs](https://enroute.osgi.org/FAQ/420-dtos.html)’s, all we need do is
> re-implement dao-impl...
- The de-coupling is not the fact that they are DTOs? If the API had defined
Interfaces or Classes the de-coupling would be the same.
- I understand the usage of DTOs for the REST service (as data are
leaving/coming) but not for the *DAO services API. The actual data leaving the
system are the *Entity classes in the implementation bundle (so the
transferable objects are converted into other transferable objects!).
- Also the fact that the DTOs are exported and used in the service contract in
the API bundle, the REST-API (and so the clients) is coupled to the internal
representation of the Java application.
I thought the DTOs was more data-api specific to a provider bundle, such as :
some-framework-rest-provider (with private DTOs) --adapt--> Java application
(with domain interface/class) --adapt--> jpa-dao-provider (with private DTOs) .
If in contrary the purpose of the DTOs is to have one consistent data
representation which evolves as soon as it is required by one of the system
(rest, java application, database-schema), how to deal with framework specific
annotations?
I hope I was clear enough!
Thanks.
--
Clément Delgrange <cl.delgra...@protonmail.com>
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
