Hi Clément, > 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. In this case the decoupling is from the data model. If the DTO types were JPA entities (i.e. they had JPA annotations on them) then everyone would be coupled to the JPA data model, and in turn, the database. You are correct that the types don’t need to be DTOs for this to be the case, however DTOs are a good choice because they force you to treat the exchanged objects as pure data, rather than an implementation specific behaviour or mapping. Perhaps a slightly better wording would be "Because of the de-coupling provided by the DTO <https://enroute.osgi.org/FAQ/420-dtos.html> package, all we need do is re-implement dao-impl…”
> 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!). As I mention above, it would be very bad for the DAO to use entity types in its API as this would force the implementation decision. The implementing bundle should be free to use JDBC, JPA, NoSQL or whatever it wants to store and retrieve values. The moment that you start talking about Entity Classes you’re already most of the way to an ORM implementation, which is one heck of an implementation internals leak. > 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. The REST API is actually not coupled to the DTO representation - the REST service implementation could do whatever transformation it chose internally. For simplicity we have chosen to keep the REST responses close to the DTOs, but we could have quite easily changed all of the field names in the JSON. Again, the OSGi implementations communicate using an API, but they can convert between internal and external representations as needed. In this case the external “REST” representation doesn’t require a transformation, but it could easily be transformed to if required. > 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) > . It’s quite the opposite - the DTOs are the public inter-bundle communication data. They are used this way in a lot of OSGi specifications. > 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? Objects annotated with framework specific annotations belong on the *inside* of the bundle using the framework - the OSGi enRoute micro service example is a great place to look. The JPA entities are internal to the JPA implementation of the Data Access Service, as it is the only user bundle that knows that JPA is being used. Best Regards, Tim > On 6 Dec 2018, at 19:30, Clément Delgrange via osgi-dev > <osgi-dev@mail.osgi.org> wrote: > > 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 > <mailto:cl.delgra...@protonmail.com>> > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
