EntityCollections and WebServices
Joined: 18-Aug-2003
Nice huh, those webservices 
You've fallen in the same trap as I have: webservices is about XML, not about serialized stuff. The reason for this is that webservices are used to transfer data in a hierarchical way (XML) to other systems which might be running another platform. When you are using .NET as the client platform, you'll see that the client is re-defining all types you return from your webservice, because in theory it doesn't know these types. Webservices in .NET work like this: everything is first transformed to Xml and that Xml is then transfered to the client, and on the client consumed (interpreted, or transformed back to objects)
.NET uses one of the most useless and crappiest designed classes ever (sorry) to create the XML: XmlSerializer. This class is very dumb, it can't work with interfaces (however the SoapFormatter can... go figure). Interfaces are required for a generic framework (MS even uses them a lot). It also requires empty constructors and other things that pollute your code. It is also badly designed because it has a hardcoded codepath for the Dataset class. Why I don't know but it signals me, something fishy is going on behind the scenes because if you need to make an exception for the 'Dataset', more classes are probably not able to be transformed to Xml by this class and cause trouble and probably need to be treated as special classes but MS didn't implement functionality for this: you can implement ISerializable (I have) but that doesn't matter... Also, don't think that when an object is serializable with Soap, it is serializable by a webservices. Apparently the Soap formatter can transform objects to Xml without a problem and can work with interfaces, the XmlSerializer cannot.
Nevertheless, some time ago I wanted to see if I could rewrite the runtime libraries to make it work with XmlSerializer. I couldn't get it to work and till today I don't know what was wrong. I rewrote all classes to work with base classes instead of interfaces. This caused some trouble for the generated code (which was unsolvable) but it was a test to use the XmlSerializer, so I ignored that. When I had rewritten it and wanted to use the objects returned from my webservice I couldn't get it to work because of the re-definition of all my objects. I had to manually change (searched for it on google and MS said in a newsgroup you should do this! 
) the generated class file on the client. I also had to define all the types I was returning as 'known types' on the webservice method. This also wasn't very nice. But when I tried to run it, it just 'hang'. The XmlSerializer got caught in an infinite loop and the server ate 10MB of memory away per second.
After 2 days of fighting with that crappy class I gave up. "Webservices is not for easy transportation of object hierarchies between .NET applications" was the conclusion. But now what to do?
----------------------------------------------------------
Solution 1: Remoting.
You should use remoting to communicate objects between .NET applications. Below I've pasted 3 blocks of code. Each block is in its own assembly: client, server and interfaces. Interfaces is necessary so server and client use the same interface to communicate with. It's a modified example from the book Programming C# by Jesse Liberty 
Interfaces:
using System;
using SD.NorthwindDAL.EntityClasses;
namespace Interfaces
{
public interface IRemoteTest
{
CustomerEntity GetCustomer(string customerID);
}
}
Server:
using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;
using Interfaces;
using SD.NorthwindDAL.EntityClasses;
namespace Server
{
public class MyServer: MarshalByRefObject, IRemoteTest
{
public MyServer()
{
}
public CustomerEntity GetCustomer(string customerID)
{
Console.WriteLine("Customer request recieved for customer: {0}", customerID);
CustomerEntity c = new CustomerEntity(customerID);
return c;
}
}
/// <summary>
/// Summary description for Class1.
/// </summary>
public class ServerTest
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{
HttpChannel chan = new HttpChannel(65100);
ChannelServices.RegisterChannel(chan);
Type serverType = Type.GetType("Server.MyServer");
RemotingConfiguration.RegisterWellKnownServiceType(serverType, "theEndPoint", WellKnownObjectMode.Singleton);
Console.WriteLine("Press Enter To Exit");
Console.ReadLine();
}
}
}
Client:
using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;
using Interfaces;
using SD.NorthwindDAL.EntityClasses;
namespace RemotingTester
{
/// <summary>
/// Summary description for Class1.
/// </summary>
class Startup
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{
// register http channel
HttpChannel chan = new HttpChannel(0);
ChannelServices.RegisterChannel(chan);
MarshalByRefObject o = (MarshalByRefObject)RemotingServices.Connect(typeof(Interfaces.IRemoteTest),"http://geek:65100/theEndPoint");
IRemoteTest server = o as IRemoteTest;
CustomerEntity c = server.GetCustomer("CHOPS");
PrintCustomer(c);
Console.ReadLine();
}
public static void PrintCustomer(CustomerEntity enCustomer)
{
// print the customer object read
Console.WriteLine("-----[Customer]--------");
Console.WriteLine("CustomerID: {0}", enCustomer.CustomerID);
Console.WriteLine("Address: {0}", enCustomer.Address);
Console.WriteLine("City: {0}", enCustomer.City);
Console.WriteLine("CompanyName: {0}", enCustomer.CompanyName);
Console.WriteLine("ContactTitle: {0}", enCustomer.ContactTitle);
Console.WriteLine("Country: {0}", enCustomer.Country);
Console.WriteLine("Fax: {0}", enCustomer.Fax);
Console.WriteLine("PostalCode: {0}", enCustomer.PostalCode);
Console.WriteLine("Region: {0}", enCustomer.Region);
Console.WriteLine("\n");
}
}
}
---------------------------------------------------------- Solution 2: Serialized text. There is another solution: if you still want to use webservices, you can use the code snippet below. The idea is this: you serialize the objects to a memory stream with Soap. The memory stream contains a string with the Soap data. You can then return the string in that memory stream as the return value of the WebMethod. On the client, create a memory stream from the string and deserialize the objects from the memory stream.
Server:
SoapFormatter formatter = new SoapFormatter();
MemoryStream writeStream = new MemoryStream();
CustomerEntity customer = new CustomerEntity("CHOPS");
formatter.Serialize(writeStream, customer);
string serializedResult = System.Text.Encoding.UTF8.GetString(writeStream.ToArray());
return serializedResult;
Client:
// serializedResult is the return value of the WebMethod called.
MemoryStream readStream = new MemoryStream(System.Text.Encoding.UTF8.GetBytes(serializedResult));
CustomerEntity customerDeserialized = (CustomerEntity)formatter.Deserialize(readStream);
Remoting is definitely the right choice it's more efficient and It Just Works(tm)
Btw: ObjectSpaces, the O/R mapper layer from Microsoft which will be part of .NET 2.0 throws the same exceptions. Let's hope MS solves the XmlSerializer to fix this so we all benefit from this, but I fear the XmlSerializer will get just another exceptional code path, especially for ObjectSpaces...
Joined: 18-Aug-2003
Joined: 18-Aug-2003
If you just want to convert it to Xml, you can use the .ToXml() method of the entity collection objects
I think that will be even better than the soap trick, because the other platforms can't convert it back to an object anyway. I understand now why you picked webservices, and I think you can best return the Xml using the ToXml() method, which converts a complete collection including entities to Xml.
Entities also have a ToXml() method.
Joined: 01-Oct-2004
Using ToXml() will give you a warning when you compile your code, as it is marked deprecated . Use WriteXml() instead. (and return the XmlNode from the webmethod)
Joined: 02-Jun-2004
Joined: 25-May-2004
I also use webservice, and on solution design we decide to not use llblgen object on the client side. The webservice had to be consumed by different type of client (.NET SmartClient and web site in php) So I wrote a DataSetGenerator, a piece of code that transform an entity (or entitycollection) to a dataset. So we use typed dataset as return type of our webmethod. Of course I also wrote an EntityGenerator to transform a typed dataset into a (collection of) entity (and keep all related object, new/dirty/deleted state etc).
Reflection powaaaa
PS : I've not use the WriteXML() method, because it's the only point of llblgen I don't like (take too much time, and generated XML is very very larger than dataset xml.
Joined: 02-Jun-2004
Correct
Joined: 25-May-2004
I don't put all llblgen properties in the dataset As I work by reflection, it's quite simple to do : I only take fields defined in the generated classes, not the fields declared in the class above (IEntity2). And if I want to add a field, It'll be directly present in the dataset In the other direction (dataset -> entity), with the RowState you know how to set the IsNew & isDirty flags (and I add an isDeleted flags)
Otis wrote:
The xml is verbose, but it contains true type information for each field. This is important when you store the data somewhere or you want to use it in whatever system, other than a dataset container.
Yes, I fully agree, but when it's not needed, it's quite useless to have the same data (field type for each entity) take a lot of place. The dream is to have the choice
Joined: 02-Jun-2004
Fabrice wrote:
I don't put all llblgen properties in the dataset As I work by reflection, it's quite simple to do : I only take fields defined in the generated classes, not the fields declared in the class above (IEntity2). And if I want to add a field, It'll be directly present in the dataset In the other direction (dataset -> entity), with the RowState you know how to set the IsNew & isDirty flags (and I add an isDeleted flags)
You can also just traverse the Fields object to grab the fields of an entity, no need for reflection
Otis wrote:
The xml is verbose, but it contains true type information for each field. This is important when you store the data somewhere or you want to use it in whatever system, other than a dataset container.
Yes, I fully agree, but when it's not needed, it's quite useless to have the same data (field type for each entity) take a lot of place. The dream is to have the choice
You'd opt for a more lightweight XML producing method overload?
Joined: 25-May-2004
Otis wrote:
You can also just traverse the Fields object to grab the fields of an entity, no need for reflection
I agree but reflection is needed - in case I add new property (computed property for example) to the entity (I work with derived entities). This property will not be in the fields list. - to add pk and fk in the generated dataset
Otis wrote:
You'd opt for a more lightweight XML producing method overload?
Exactly !
But .. for me it's allready too late, I can't change that so close to the release
Fabrice wrote:
Otis wrote:
You can also just traverse the Fields object to grab the fields of an entity, no need for reflection
I agree but reflection is needed - in case I add new property (computed property for example) to the entity (I work with derived entities). This property will not be in the fields list. - to add pk and fk in the generated dataset
Good points
Otis wrote:
You'd opt for a more lightweight XML producing method overload?
Exactly ! But .. for me it's allready too late, I can't change that so close to the release
I'll see what I can come up with in the future, I'll add it to the todo list. (although I really hate XSchema...)
Joined: 25-May-2004