case for Fake Entity ?

[Jack Bakker, modifié il y a 6 années.]

If I have a Category (in a Vocabulary) with properties (key/value). One property might be: key=MyKey value=MyValue. Let's say I want a beanLike "MyCategoryName" that has a method that returns "MyValue" like:

public String getMyKey(){
...
}

Would use of a Fake Entity be a good fit for this need ? (changing category property "keyName" would break this, yeah).

And a good fit, then what about doing something similar for entities with many custom fields... like MyOrganizationOnExpandoSteroids ?

A goal here is that the remote service on the fake entity could then could provide the json

[David H Nebinger, modifié il y a 6 années.]

I think it would be a use case...

I don't believe expandos are ever included in the JSON reply, so it would be a way to include additional fields to effectively "flatten" the hierarchy.

But I think you could also make the argument that using the simpler JSON annotations to use your own DTO mechanism.

But me? I'd probably go with the fake entity approach. It might seem "change resistant", but personally I like that SB generates all of that boilerplate code so I don't have to worry about it. But I can understand where others might prefer the "lighter" touch...






Come meet me at Devcon 2017 or 2017 LSNA!