A good example for the usage of DTOs is: http://javadox.com/org.osgi/osgi.cmpn/6.0.0/org/osgi/service/component/runtime/ServiceComponentRuntime.html
Christian Am Fr., 7. Dez. 2018 um 12:07 Uhr schrieb Clément Delgrange via osgi-dev < osgi-dev@mail.osgi.org>: > Hi, thanks for your response. > > 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... > > > I agree, I would not replace API parameters with entity types I meant > replacing entity types with DTOs and API parameters with plain Interface or > Classes. > > The REST API is actually not coupled to the DTO representation... > > > Yes indeed. > > 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. > > > I looked at the R7 osgi.cmpn in the org.osgi.service.* packages but I did > not see services using DTOs in that way, maybe have you a link? Or better a > realistic project that use DTOs for service parameters and return type?. > > Your response clarify a the way enRoute proposes to use DTOs but it is > still hard to now when to use them. For example, if the microservice > example change: now the REST service does not call the DAO layer directly > but a PersonManager service that will send events, call other services, ... > and finally call the DAO layer. The PersonManager service has almost the > same methods than the PersonDao service, do you use DTOs for the > PersonManager service? In this way DTOs seem less flexible than interfaces > for parameters/return types, if later we want to add a `getFullName` or a > method to filter Addresses? As mentioned in the tutorial, DTOs are not > immutable or thread safe, does that mean each time you call a service you > copy them? > > Clément. > -- > Clément Delgrange <cl.delgra...@protonmail.com> > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Friday, December 7, 2018 11:09 AM, Tim Ward <tim.w...@paremus.com> > wrote: > > 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...* > > > > 1. 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. > 2. 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!). > 3. 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 > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
