lyndon_h wrote:
Kristian wrote:
Hello,
Since you plan on creating a distributed architecure, I would go with the adapter scenario, which splits out the persistence info, from the actual domain entities. Also, the entities are already marked as serializable right out of the box, so you should be good to go.
I could be wrong, but i thought that there was a problem with circular dependencies with objects and the ISerializable interface. I think you have to jump through a couple of loops in order to get webservices working with webservices.
Webservices don't use the ISerializable interface, but use the XmlSerializer, which uses the undocumented IXmlSerializable interface, which is only implemented on the dataset.
The xmlserializer is a crappy class, it can't deal with cyclic references as you mentioned, nor can it handle hashtables and interface based types. Furthermore, it thinks that every class which implements IXmlSerializable is a dataset.
The current code is therefore not directly compatible with webservices, as in, an entity is not returnable from a webmethod. You can however return the XmlNode from the webmethod, which is filled by WriteXml() on an entity.
The webservices code in vs.net is also not that clever. If you embed a webreference in your project, vs.net will generate NEW classes for the types returned from the webservice. You don't want that, as you want to use the rich entity objects of the generated code. To make that happen, you have to alter the vs.net generated mock objects (according to MS support), but this is of course not that great, because your changes are not preserved when the stuff has to be regenerated by vs.net.
So, if you have a .NET client and a .NET service, please use remoting. It's build into the code and works flawlessly. If you have a .NET service and a non-.NET client, webservices are your goal, and you then should return as raw xml as you can, so the non-.net client can consume it.