I am considering using CSLA .NET DataSource as input to YUI DataSource http://developer.yahoo.com/yui/datasource/, to get results as JSON from the CSLA DataSource.
I am just wondering if any work has been done on this before ?
In other words, I want to add a Shared Method to an existing CSLA Business Object to return the object content as JSON.
Appreciate your feedback/comments.
Tarek.
A JSON interface is the same as an XML interface - in both cases you are talking about building an interface on top of your objects.
Chapter 21 in Expert 2008 Business Objects talks about building service interfaces on top of objects. While I don't specifically discuss JSON (or REST), the concepts from the chapter are valid for those technologies just as much as for XML services.
I am not familiar with this YUI library, and don’t have time to
research it now, so I don’t know that I can answer.
No, you do not need to upgrade CSLA. You can read Chapter 11 of
the Expert 2005 Business Objects book and the concept is the same.
JSON or XML services should be considered to be an interface
over your objects, just like HTML is consider to be an interface. Business
objects should not know how to generate the interface – that way leads to
disaster (are you going to have ToXml(), ToJson(), ToHtml(), ToWindowsForm(), ToXaml()
and other methods on every object?).
I think my previous post should have been clear.
If you add ToXml(), then ToJson(), why not ToHtml()? And
ToAjaxHtml() and ToXaml()?
You are mixing the concept of interface into your
business layer, which breaks down the architectural separation of concerns.
What happens when you learn that the way you render your XML or
Json doesn’t match someone’s needs? Do you have ToJson() and ToJson2() and
ToJson3()?
Putting interface code into the business layer breaks the
layered architecture concept, and leads to unmaintainable code.
You will probably be well-advised to read the chapters on XML services and CSLA, and to get familiar with XML Web services. Since you're still in VS 2005, you'll have to roll your own JSON support, but it basically works the same as an XML service. Essentially, you are building another interface on top of your BO's, much like an ASPX page. However, in the XML case, it's an ASMX page which handles the XML translation for you. If you need JSON, then you can build ASPX pages and use Response.Write. If you want to handle both types within a single page, then you can do your XML translation in an ASPX page as well, but you'll have to do it by hand, just like you do your JSON format.
You don't build your BO's to deal with that interface - you use the interface to shape what your BO's return. That doesn't mean you create wrapper classes for each of your BO's - the code-behind of your service page is doing the wrapping for you. If you need multiple data shapes from your BO, those become multiple methods on your service page, or different service pages. But you don't do anything to your BO's.
HTH
- Scott
tmg4340,
May thanks for the reply.
When you say XML Service, you actually mean a Web Service ? Using SOAP Format ?
I am very much familiar with developing Web Services as a wrapper for CSLA .NET Business Objects. Very easy job for me. But the problem here (as per my understanding) is that the YUI DataSource does not understand the results of SOAP Based XML Reply (Web Service), and in turn, cannot consume such XML web services.
It appears to me that I have to develop a wrapper of some kind that will generate the XML representation of the Business Object as per the format required by the YUI DataSource Control.
Appreciate your feedback/advise.
Tarek.
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?
I found the following additional resource related to this topic for those who are interested:
http://developer.yahoo.com/yui/examples/datatable/dt_xhrpostxml.html (for this exmaple, the source is XML and is located here)
http://yuiblog.com/blog/2008/10/15/datatable-260-part-one
http://mattberseth.com/blog/2008/09/dynamic_data_experimenting_wit.html (this example uses .NET 3.5, Json Built-in support in .NET, Web Service, and YUI DataTable.)
Tarek.
Just a quick update on this topic.
With EssentialObjects Grid Control (and probably other controls too), there is no need to serialize Csla Objects to XML nor Json. EO.Web Controls supports CslaDataSource out of the box.
See this link for more details:
http://forums.lhotka.net/forums/p/8758/41666.aspx#41666
Tarek.
Copyright (c) Marimer LLC