Closed Mardoxx closed 7 years ago
Thanks for the report, we will take a look at this and see what we can do.
This seems like a good place to use a library such as AutoMapper to modify the objects and apply the data from the original User/UserGroup objects to the DTO.
Closing because there are no plans to implement this.
@Eilon This is one of the solutions I ended up at, but I didn't really like it because it involves a lot of boilerplate, and the naive way I implemented it involved 3(!) calls to the db - which is obviously terrible! Really felt like I was forcing it to do something it doesn't want to do -- using the wrong tool for the job I think!
Thanks for looking in to this though! :)
A somewhat contrived, but nonetheless important, example.
Assume the following case whereby
UserDetails
is an aggregate DTO (not sure of correct terminology, but basically a model of collected information from different stores/services) which is used by a RESTful web service. It does not necessarily have the same property names as the objects it collects together.Let our stores persist the following models:
Let the UserDetails object be populated thusly:
That is, setting
FirstName
orSurname
should delegate to theUserService
, andUserGroupId
to theGroupService
.This
UserDetails
object is used for GET and PUT, the logic here is pretty trivial, however a JSONPatch document for this object is sent for PATCH requests. This is apparently much more complicated.How can we go about changing the user's group? The best ('best' being used very loosely) I came up with is this:
Which is pretty garishly awful. It's a lot of boilerplate, and relies on a magic string.
Something like
patch.Path(x => x.UserGroupId )
which returns"/userGroupId"
would at least get rid of the magic strings.JsonPatch seems pretty limited in this regard, seems more tailored towards systems where there is a 1:1 mapping between DAO (entities) and DTO (model). Anyone got any good ideas? Can't be hard to beat the tripe I came up with!!