WCF service to return XML: is CSLA a fit for this scenario?

sami posted on Friday, October 09, 2009

We provide a SaaS application which uses a WinForm client app communicating through the backend via WCF. Our application is strictly built on the CSLA framework.


Nonetheless, it seems that I need to do something slightly out of the norm and would like some advice. I’m adding a WCF service that needs to hand back an XML Document to the client application. The service currently does not hand back an object (or collection) because the database call returns XML (using FOR XML in stored procedure). Now, while the XML does describe one or more complex business objects, it doesn’t make sense to build a list of objects and then put them back into XML. The query can change anytime so it needs to be agile; making business object changes to reflect the data and then recompiling/deploying wouldn’t be worth it (a third party company determines the structure).


The question I have is how would this service, which hands back XML, fit into the CSLA framework?


I guess another question is: Does the service need to go through the business layer if there are no business objects constructed or validated?


In other words, is CSLA a fit for this type of scenario and, if so, do you have any examples for it?

RockfordLhotka replied on Friday, October 09, 2009

I think you should always look at a technology or framework and decide to use it based on whether you need its features. Factors for CSLA decisions include:

1. Are you already using CSLA .NET in the app? If so, you should probably be consistent everywhere
2. Do you need to centralize business logic into a business layer?
3. Do you need the data portal (location transparency - switch from 2-tier to 3-tier via config)?
4. Do you need data binding?

For an XML interface number 4 isn't so useful.

Number 3 might be important, depending on your environment.

Number 2 sounds like it isn't important, becuase it sounds like you have no business logic - this is a straight data feed.

Number 1 is important - consistency is very important imo.

Assuming you decide you should use CSLA .NET, that doesn't mean you have to load/unload an object graph. You could use a simple model where you have a business object that has one property: the XML string from the database.

No business, validation or authorization logic - just a data dump. But you'd retain architectural consistency with the rest of the app and retain the ability to use the data portal - both of which might be very valuable.

If the data flows outbound only I'd use a ReadOnlyBase object. If the data is bi-directional you might use a CommandBase object. Either way, the string data type is serializable, so just get the XML string from the database, put it in the property and dump it into the Response stream.