Here's a generic method that I wrote that serializes a data type to a
string:
/// <summary>
/// Builds the Serialized xml that represents the specified object
/// </summary>
/// <returns></returns>
private string GetSerializedXML<ItemType>(ItemType item) {
//Serialze this object and send to the webservice.
XmlSerializer xs = new XmlSerializer(typeof(ItemType));
StringWriter sw = new StringWriter();
xs.Serialize(sw, item);
return sw.ToString();
}
On 7/12/06, Don Demsak <[EMAIL PROTECTED]> wrote:
Mike,
Check out this post by Matt Berther, "Web service and custom
serialization"
http://www.mattberther.com/2006/05/000755.html. In that post, Matt
is running into issues where he is trying to reuse his business objects as
message objects, because he doesn't want " two copies of the objects", one
for XML serialization and one for the business entity, which sounds like
you
are trying to do a similar thing. The best practice is that if you are
using business objects, odds are that you will need a separate message
object to serialize. My detailed response was:
I'd suggest that you have 2 copies of the "objects", even though you think
it stinks. You have to remember that even though the "objects" have the
same
name, they are actually built to accomplish 2 different goals. The class
that you have now, it is a business object, and thus has to conform to
your
business rules (which is part of the reason why you don't have a default
constructor). Business classes contain the business data and the business
behaviors. On the other hand, you have this representation of your
business
object that you wish to pass along the wire. The representation is a
message, and not a business object. This class will contain a
representation
of the data contained within the business object, but as it is a message,
it
contains no business rules.
Once you decouple the message from the business object, you will have an
easier time distinguishing between your core business rules, and your
message rehydration rules. In do so, you are also better able to handle
versioning of your public facing contracts (in web services this is done
via
WSDL and XML Schema). You can now update and change your business objects
as
needed, and only add any new data to your message when that new
functionality is required. By going down this path you will also be able
to
utilize the more enterprise friendly Web Services Contract First approach
to
building web services.
I know that there are a lot of people that will disagree with me, and feel
as you do, that by splitting things into messages and business objects,
you
are just adding to the bloat of a system, but I've learned that as long as
you don't hit the architectural issues that you discuss here, that yes,
the
message based methodology is overkill for your particular project. But
once
you start to see that there are differences between the way you want to
implement the business object, and the way you want to represent it on the
wire, then you need to start to think about going down the message path.
A comprising between these 2 designs is to implement the IXmlSerializable
interface, on your business classes, but eventually this will also become
too cumbersome and you will have to go the route of the message
methodology,
especially when you have to handle multiple minor versions of your message
coming thru the same web service.
Don Demsak
www.donxml.com
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
