Derived types and backend.

I want the server side (sql and business logic) to know about one type. And
the client app(s) could derive there own types as needed but also store
their derivations so they can deserialize them. Is there a pattern for
this? What I am thinking now is simple example like:
public interface IVehicle
{
string Name
{
get;
set;
}
string Type
{
get;
set;
}
string Guid
{
get;
set;
}
public class Vehicle : IVehicle
{
private string name;
private string type;
private string data;
public string Name { get/set imp }
public string Type { get/set imp } // Derived type name. Used by
client to know how to deserilize Data.
public string Data { get/set imp} // Derived types xml.
}
So server knows about the Vehicle type and that is all. It can store three
columns: Name, Type, and Data.
If a client just wants to use Vehicle(s) then it is all set. However, it
may want to derive a Corvette or some other vehicle from base like so.
public class Corvette : IVehicle
{
private string name;
private string type;
private string data;
// Derived fields.
private string color;
public string Name { get/set imp }
public string Type { get/set imp }
public string Data { get/set imp}
public string Color { get/set imp}
public Corvette() { }
public Corvette(Vehicle vehicle) { //create a corvette from a vehicle. }
}
So I can get Vehicles from the server and create Corvettes on the client
side. However I need to store back a Corvette on the server, but the server
only knows about Vehicle type. So I am thinking serialize the Corvette type
into xml string, create a new Vehicle using same Name. Set vehicle.Type to
"Corvette" and store xml string in vehicle.Data. Now send the Vehicle type
to server for storage in SQL using the 3 columns in Vehicle. Now if the
client needs Corvette type, it gets the Vehicle, checks the Type and
deserializes the Data string into Corvette type and uses it. So that is the
round trip. Not pretty, but only way I can figure so far to do it. Any
ideas? TIA
--
William Stacey [MVP]
William Stacey [MVP]There was an MSDN article written by Andrew Conrad that covers a scenario
very close to what you want to do. He uses an xml overflow column to store
the additional properties of the subclass.
"Death, Taxes, and Relational Databases, Part 1"
http://msdn.microsoft.com/library/d.../>
4212003.asp
Specifically the section entitled: "Extending the Business Objects"
"William Stacey [MVP]" wrote:

> I want the server side (sql and business logic) to know about one type. A
nd
> the client app(s) could derive there own types as needed but also store
> their derivations so they can deserialize them. Is there a pattern for
> this? What I am thinking now is simple example like:
> public interface IVehicle
> {
> string Name
> {
> get;
> set;
> }
> string Type
> {
> get;
> set;
> }
> string Guid
> {
> get;
> set;
> }
> public class Vehicle : IVehicle
> {
> private string name;
> private string type;
> private string data;
> public string Name { get/set imp }
> public string Type { get/set imp } // Derived type name. Used by
> client to know how to deserilize Data.
> public string Data { get/set imp} // Derived types xml.
> }
> So server knows about the Vehicle type and that is all. It can store thre
e
> columns: Name, Type, and Data.
> If a client just wants to use Vehicle(s) then it is all set. However, it
> may want to derive a Corvette or some other vehicle from base like so.
> public class Corvette : IVehicle
> {
> private string name;
> private string type;
> private string data;
> // Derived fields.
> private string color;
> public string Name { get/set imp }
> public string Type { get/set imp }
> public string Data { get/set imp}
> public string Color { get/set imp}
> public Corvette() { }
> public Corvette(Vehicle vehicle) { //create a corvette from a vehicle.
}
> }
> So I can get Vehicles from the server and create Corvettes on the client
> side. However I need to store back a Corvette on the server, but the serv
er
> only knows about Vehicle type. So I am thinking serialize the Corvette ty
pe
> into xml string, create a new Vehicle using same Name. Set vehicle.Type t
o
> "Corvette" and store xml string in vehicle.Data. Now send the Vehicle typ
e
> to server for storage in SQL using the 3 columns in Vehicle. Now if the
> client needs Corvette type, it gets the Vehicle, checks the Type and
> deserializes the Data string into Corvette type and uses it. So that is t
he
> round trip. Not pretty, but only way I can figure so far to do it. Any
> ideas? TIA
> --
> William Stacey [MVP]
> --
> William Stacey [MVP]
>
>|||Thanks Todd. :-)
William Stacey [MVP]
"Todd Pfleiger [MSFT]" <ToddPfleigerMSFT@.discussions.microsoft.com> wrote in
message news:3B2852EA-495E-4D03-8CD7-10646EEF42E4@.microsoft.com...
> There was an MSDN article written by Andrew Conrad that covers a scenario
> very close to what you want to do. He uses an xml overflow column to store
> the additional properties of the subclass.
> "Death, Taxes, and Relational Databases, Part 1"
> http://msdn.microsoft.com/library/d...
l04212003.asp
> Specifically the section entitled: "Extending the Business Objects"
>
> "William Stacey [MVP]" wrote:
>