My advice: just think of it as “dumb” data, nothing else. If you need to ensure invariants, create some kind of wrapper around it.
My thought is that the domain object would wrap the DTO, and the DTO is only holding the state. Only the domain object, which understands the invariants and business rules, should be able to write to the DTO. Cheers, =David > On Aug 18, 2016, at 9:50 PM, David Daniel <[email protected]> wrote: > > So copy could work for immutability but it limits my ability to help the > client (which is normally me and I am definitely stupid enough to not think > about how I designed the system) but it doesn't help with how to add > mutability of data objects transferred between services. I do think I may > be trying to do too much with DTO's but I am still trying to wrap my head > around where they should be used. Do I just use them as pojo's that come > in and out of services and then immediately convert them to domain specific > objects or do I let them stick around and try and make use of them. > > On Thu, Aug 18, 2016 at 8:26 AM, David Leangen <[email protected]> wrote: > >> >> David D., >> >> No! You just need to copy the DTO. Let the client do whatever it wants >> with the DTO; it won’t mess up the system. If the client is “stupid” enough >> to change the value of the DTO, then that’s the client’s problem. >> >> There is no more worry about immutability / value object. There are only >> copies of objects. >> >> BTW, that is why I suggested that we add a copy() method. >> >> It does take a change of mindset. I also came from the School of Immutable >> Objects. But copying objects works, too. >> >> >> Cheers, >> =David >> >> >> >>> On Aug 18, 2016, at 9:16 PM, David Daniel <[email protected]> >> wrote: >>> >>> So for the article above what I am struggling with is how to do >>> immutability/mutability with the DTO spec. With java beans there is a >> get >>> and set method for each attribute. If DTO's had this the way I would do >> it >>> is as follows. I would have an attribute for mutability that is either >>> true or false. If false I would put an aspect around the get function >> that >>> returns a clone of the attribute value. I would put an aspect around the >>> set function that throws an exception. For mutable DTO's my converter >>> would delegate deserialization to a CRDT service that would put aspects >>> around set that watches for changes and aspects around get/set that >> throws >>> an exception if called when the DTO is in a conflicted state. The CRDT >>> service would then return the DTO to the converter. On update it >> modifies >>> the CRDT structure as above. In the converter if the DTO is watched then >>> when serializing it delegate serialization to the CRDT service. I am not >>> sure how to model immutability with the current DTO standard because >> there >>> are no get or set functions that I can put aspects around. >>> >>> On Thu, Aug 18, 2016 at 6:40 AM, David Daniel < >> [email protected]> >>> wrote: >>> >>>> For me helps by having the schema that allows for something some other >>>> service uses to do the automatic merging using the tools available in >>>> dosgi, but I understand that nothing can be really automatic because it >> can >>>> require merges and there is garbage collection that will need to happen >> on >>>> the objects during reconciliation. If the DTO's are just public fields >>>> they do not offer anything over using a pojo. Where they start to be >>>> useful to me is by defining in a standard way how the data can be turned >>>> into an object. Examples would be a way to define a key so that indexes >>>> and equality can be determined, or defining relationships between sub >>>> objects so when doing a deep clone the user can decide how many links to >>>> traverse. Scoping rules could also be defined so the converter has >>>> information that could be used in determining which type of object to >>>> serialize to in different situations. The standard can choose not to >>>> define these things and let the application decide in order to be more >>>> flexible or it can try to define some of these things in order to make >>>> services or tools around DTO's more standardized. I think I am trying >> to >>>> follow what schema elements will be in DTO's and make sure that I take >>>> advantage of them rather than writing my own. As of right now that I am >>>> just using them as pojo's though so I don't have any feelings or advice >> on >>>> the way to go and what types of schema things I would be able to take >>>> advantage of. >>>> >>>> On Thu, Aug 18, 2016 at 4:23 AM, David Bosschaert < >>>> [email protected]> wrote: >>>> >>>>> Hi Davids, >>>>> >>>>> What is it exactly from that article that you think would make sense in >>>>> the >>>>> context of OSGi? The automatic merging of concurrent data updates? >>>>> >>>>> Thanks, >>>>> >>>>> David >>>>> >>>>> On 18 August 2016 at 07:50, David Leangen <[email protected]> wrote: >>>>> >>>>>> >>>>>> That is interesting, indeed! I only quickly skimmed through the >> article, >>>>>> but it does indeed appear to be a potentially interesting property for >>>>>> dosgi. >>>>>> >>>>>> If I believe what the authors write in the abstract, it provides a >>>>>> relatively simple and deterministic method that could be implemented >> in >>>>>> code. >>>>>> >>>>>> Cheers, >>>>>> =David >>>>>> >>>>>> >>>>>>> On Aug 17, 2016, at 10:21 PM, David Daniel < >>>>> [email protected]> >>>>>> wrote: >>>>>>> >>>>>>> read an interesting article this morning >>>>> http://arxiv.org/abs/1608.03960 >>>>>>> Something like this would be an interesting property to have for >> dosgi >>>>>>> which is one of the use cases for DTO's >>>>>>> >>>>>>> On Wed, Aug 17, 2016 at 6:47 AM, David Leangen (JIRA) < >>>>> [email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> [ https://issues.apache.org/jira/browse/FELIX-5325?page= >>>>>>>> com.atlassian.jira.plugin.system.issuetabpanels:comment- >>>>>>>> tabpanel&focusedCommentId=15424288#comment-15424288 ] >>>>>>>> >>>>>>>> David Leangen commented on FELIX-5325: >>>>>>>> -------------------------------------- >>>>>>>> >>>>>>>> Awesome. Thank you! :-) >>>>>>>> >>>>>>>>> Patch for embedded DTO (in DTO) >>>>>>>>> ------------------------------- >>>>>>>>> >>>>>>>>> Key: FELIX-5325 >>>>>>>>> URL: https://issues.apache.org/jira >>>>> /browse/FELIX-5325 >>>>>>>>> Project: Felix >>>>>>>>> Issue Type: Improvement >>>>>>>>> Components: Converter >>>>>>>>> Reporter: David Leangen >>>>>>>>> Assignee: David Bosschaert >>>>>>>>> Priority: Minor >>>>>>>>> Attachments: patch.diff >>>>>>>>> >>>>>>>>> >>>>>>>>> This patch adds support for converting a DTO that contains an >>>>> embedded >>>>>>>> DTO. It uses recursive calls to Converter.convert() to accomplish >>>>> this. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> This message was sent by Atlassian JIRA >>>>>>>> (v6.3.4#6332) >>>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >> >>
