Thanks for the link!
--
Clément Delgrange <cl.delgra...@protonmail.com>
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday 7 December 2018 13:08, Christian Schneider <ch...@die-schneider.net>
wrote:
> 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...
>>>>
>>>> - 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
>>
>> _______________________________________________
>> 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
