When you say Stored Procedure input and output values
will be XML you mean the application will only support
SQL Server? How are you planning to handle the XML?
The long term goals of the CSK 2.0 is to make it
non-dependant on any one database platform. However, for
the first cut it will be built against SQL 2000.
The next major piece of information is we are building
data providers. These break down to User/Security, Site,
WebApp (one app can have many sites!) and Content.
With all of this in mind, the Content_Sql provider(s)
will be using XML to talk to SQL server. When we go to
add new providers it will depend on if they handle XML.
If not, the XML will need to be broken back to typical
ADO.NET structures to talk with that data store. Each
case will be handled individually.
What this gives the developer of any CSK module is the
liberty to develop and only have to learn a single
provider interface and the data providers handle
everything from there.
Are you planning on use the Provider Design Pattern to
abstract an API for the data providers?
Could you explain why the design decision was made on
using XML as input/output? As for input parameters,
would it be only one? or many of the varchar type?
I was used to use XML as output with SQL 2000 back on
the old days of ASP 3.0. But I haven't use this approach
on any of my .NET applications yet.
I'm hoping to address this in another article real soon.
The skinny of it is this:
Using XML I won't have to change my data providers if I
decide to add/delete/change a column or two. The data
providers will consume and produce XML on the UI side
and will talk with the data stores via SQL if it can or
in the data store native language at worst.
Hope that makes sense.
(Once I have my .Text site up and running I plan to add
diagrams to the articles so it can be pictured easier.)