Sending POCO DTO objects from Server to Client? #3059
-
What's the recommended way to send POCO DTO objects over the wire without CSLA classes? I've experimented with the following CSLA wrapper which uses [Serializable]
public class CslaJsonWrapper<T>
: ReadOnlyBase<CslaJsonWrapper<T>>
{
public static readonly PropertyInfo<string> JsonProperty
= RegisterProperty<string>(nameof(Json));
public string Json
{
get => ReadProperty(JsonProperty);
private set => LoadProperty(JsonProperty, value);
}
public T GetObject()
{
return JsonSerializer.Deserialize<T>(Json);
}
private void SetObject(T obj)
{
Json = JsonSerializer.Serialize(obj);
}
[Fetch]
[FetchChild]
private void Fetch(T obj)
{
SetObject(obj);
}
} This can be used with a |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 5 replies
-
I don't know that I'd call this a recommended way, but on the rare occasion that I've needed to send a POCO to or from the server without a business object base, I've just implemented IMobileObject.
I suppose I could have a base class that used reflection, etc, to do this for me, but it hasn't really come up too many times, to be honest. Also, I wouldn't say that this is better than what you're doing. It's just what I've done in the past. |
Beta Was this translation helpful? Give feedback.
-
As part of the work for CSLA 6 I wrote a source generator to automatically implement IMobileObject, triggered by attributes applied to the class. This was intended for use on DTOs. However, we found a problem with it when it came to using it on .NET 6, and I realised it needed to change to overcome the problem. When I subsequently tried to rewrite it to overcome the .NET 6 problem I hit an issue with debugging it - some change to Visual Studio I think, and so it became difficult to fix. After struggling for a while to get debugging to work, I had to sideline it for more important things, and as a result, it didn't make it into the package. It is work I intend to revisit at some point, but I'm not sure when. It became less attractive when I realised that it could potentially open a bit of a security vulnerability in people's systems. The flow you are using wouldn't be a problem - server to client would be OK. However, the flow in the other direction might be problematic because there are no validation rules applied to a DTO, so an end user could submit anything to the server and have it processed without checks being applied. That doesn't make it useless, but it does make it less useful and more difficult to educate about. |
Beta Was this translation helpful? Give feedback.
-
Another option that just occurred to me is that you could have one root domain class that serializes your POCO graph into a JSON string, and so the domain class would just have that one It would then have |
Beta Was this translation helpful? Give feedback.
Another option that just occurred to me is that you could have one root domain class that serializes your POCO graph into a JSON string, and so the domain class would just have that one
string
property containing the JSON.It would then have
SetData(object graph)
andobject GetData()
methods to convert the graph into and out of the JSON string.