CSLA and JSON (serialization for lists)

CSLA and JSON (serialization for lists)

Old forum URL: forums.lhotka.net/forums/t/8473.aspx


decius posted on Thursday, February 04, 2010

I've just recently started using my CSLA objects along with JSON in my AJAX. It's been working great for single objects, but I'm struggling with lists. When I get my list to the presentation layer and send it back I keep running into walls with the serialization from json back to the csharp csla object.

Has anyone had a lot of experience with this? Maybe someone could nudge me in the right direction.

I've been using the JavaScriptSerializer to get it to and from. Having trouble deserializing lists though.

RockfordLhotka replied on Thursday, February 04, 2010

You should never directly serialize business objects into XML or JSON for external consumption. I've discussed this numerous times, including in Chapter 21 of the Expert 2008 Business Objects book and in the FAQ

http://www.lhotka.net/cslanet/faq/ObjectsAsServiceContract.ashx

Instead, you should define a data contract for the external interface, and load/unload the data contract proxy objects from your business objects (possibly using DataMapper).

decius replied on Thursday, February 04, 2010

ack. I see what you're saying: couples the presentation layer.

Sigh. It was so clean and easy that way tho.... ah well

But isn't databinding to webforms essentially the same concept??? Changing your objects breaks that 'consumer' as well. Isn't coupling ultimately inevitable to some degree?

RockfordLhotka replied on Thursday, February 04, 2010

I think data binding (web forms, windows forms and especially XAML) provides a layer of indirection and decoupling between the view and model; between the UI and business layers.

Data binding uses reflection to do its work, and isn't actually type-specific. In other words, you can typically provide any object that has the right shape and it will work. As long as the object exposes the properties required by data binding (whatever is bound to the UI) all is good.

So yes, there's a level of coupling, but it is generally pretty low.

decius replied on Thursday, February 04, 2010

For others interested:

Rocky, your quote from http://forums.lhotka.net/forums/thread/37549.aspx really helped

Rocky:

Yes, you should create another object that maps the business layer information to the interface layer.

This is what an ASP.NET Page (aspx, etc) does to get business object properties into HTML, and is exactly what you should do for a service.

You can do this as you suggest, with an aspx page that writes out the stream. Or an asmx page. Or as you say, an HttpHandler.

But a lot of people do this sort of thing with an aspx page.

Technically you don’t need some other object either – the generation of XML or JSON can be done in the aspx page.

Which almost makes sense if you think about it – an aspx page usually renders HTML, you are just having it render JSON or XML.

And if you want a page with a different format you create a different aspx page right? So if you need different XML or JSON you’d just create a different aspx page for that too. Otherwise how does the calling app know what it is asking for?


So now I'll just make some simple dto classes and load/unload at the interface of the service and only expose those classes instead. I can then use JavaScriptSerializer on THOSE classes, coupling presentation only to the interface like suggested.

A little bit more code but a LOT less coupling.

rasupit replied on Thursday, February 04, 2010

decius:
So now I'll just make some simple dto classes and load/unload at the interface of the service and only expose those classes instead. I can then use JavaScriptSerializer on THOSE classes, coupling presentation only to the interface like suggested. A little bit more code but a LOT less coupling.


Great choice and also from security perspective too.  This way you only expose the properties you want to expose and not allowing anybody calling your webservice with tempered json object.

Ricky

decius replied on Thursday, February 04, 2010

Cool. My only question now is for when I get back to loading changed values to my csla object when receiving changed data on the interface.

Specifically for lists. Will I have to loop through each object performing object something like below?? I've never had to do more than simple tasks with the datamapper.

foreach (var copyFrom in receivedDto)
{
var copyTo = serverCslaList.Where(x => x.Id == copyFrom.Id).Single();

Csla.Data.DataMapper.Map(copyFrom.Values, copyTo);
}

Copyright (c) Marimer LLC