Obviously the complexity of thiscould go off the charts. And you’re right the obvious complex solution would be agrest. I’m thinking of the opposite extreme. One DTO object per entity.
Double bonus points if the DTO has two methods, entityToDTO and dtoToEntity. Relationship data can be as complicated and varied as use cases but a check box on the entity that created a DTO with just the attributes would certainly make my life easier. Mike Gentry’s idea of using Jackson I personally don’t like. DTO and entity perform two different tasks and I don’t want to intertwine them. I recognize they are awfully close in nature and using Jackson is tempting but we still create DTOs. I’ll have to think on that more. Case by case you have to decide which relationships you should bundle back but more and more I like links to fetch related data. Again not always appropriate but if you have DTOs readily made you can bundle them up in the payload as well. The other advantage of this is that you could market AGRest as the next step beyond the DTO solution that comes in Cayenne. Edge cases are always where the devil lives. :-) Thankfully we’re here to solve those problems. Tony Giaccone > On Sep 18, 2019, at 2:21 AM, Andrus Adamchik <[email protected]> wrote: > > Ignoring serialization mechanics (and even the presence of Cayenne) for a > moment, I was always wondering how do people even approach this problem. > Every persistent object is potentially an entry point to a near-infinite > graph of objects coming from DB. So you need to have a set of clear rules of > how deep and wide you want to go when you start serializing. > > DTO is one way to define such rules. But unless your rules are very simple > ("send the attributes, don't send the relationships"), if you start > generating DTOs, they will have the same set of relationships. And you'd end > up with the same issue as you had with serializing the original DataObjects. > > So what parts of the graph do you need to serialize? > > And if this needs to be flexible, I would probably write a small library that > allows a user to define a subset of model to serialize, and then applies that > "submodel" to DataObjects directly (this is the Agrest.io approach on a > smaller scale). But as with any generic solution, this will require a bit of > effort, dealing with edge cases, etc. > > Andrus > > > >> On Sep 18, 2019, at 12:29 AM, John Huss <[email protected]> wrote: >> >> It's a small effort to create a custom entity template to generate any kind >> of entity class you want, for instance for a DTO. You can copy a lot of >> stuff right out of the regular templates if you want. >> >> Then you can use maven or ant to easily regenerate those classes the same >> way CayenneModeler does without having to change the custom template >> selections all the time. >> >>> On Tue, Sep 17, 2019 at 1:49 PM Tony Giaccone <[email protected]> wrote: >>> >>> So typically I create a Data Transfer Object to return values across the >>> wire that I have fetched and copy attributes from my model object to the >>> DTO. This gets tedious quickly. I wondered if there's not another way >>> that people are doing this, because this seems entirely too painful. >>> >>> However, if* this is* what most people do, then perhaps a change could be >>> made to the modeler, that would all you to create automatically a set of >>> DTO objects with when you generate the model objects. I recognize that >>> this would be a rather significant effort and I'm guessing that there's >>> probably a better way, but I'm not aware of what it is. >>> >>> Any suggestions? >>> >>> >>> Tony Giaccone >>> >
