We certainly may not have the right object model. I have glossed over
the details of how the clients of the web service handle the data just
to try to keep things simple, but perhaps a better explanation is in
order. 99% of the time the clients will know what type of item they
are requesting.
Our clients really come in two flavors:
1. Read-only, informational clients that wants to reference the fields
of the 'object' (this object is read as an XML document or
deserialized into the .Net class for .Net applications) in some
manner, either to the end-user in either a form or browser based
application, or as part of some calculation based on data gathered
from other sources (and then displayed on something or store somewhere
else). These clients know where to get the schema definition of the
objects that we are returning through our web service. Like I said
they know they are requesting a 'Foo' object and will get one. The
types of these applications range from our ERP product (SAP) to
applications that run on our manufacturing floor to reporting-based
applications.
2. We have a form based client that handles creating and configuring
these objects (just think of a standard configurator-type of
application - its is a little more complicated than that). We
actually don't manipulate the object coming back from the web service
- that object is just a DTO object (
http://en.wikipedia.org/wiki/
Data_Transfer_Object) that is just used to for data transversal
between our domain and client tiers. We use this DTO to construct a
traditional complex domain object with state that is used by this
client. When we are ready to save this business object it gets
translated back into the DTO to be passed back to the web service
(which leads to a similiar question of what type of parameter this DTO
object should be in - currently it is just a .Net string again). The
complex object has the capability to generate a DTO of itself or
initialize from a DTO (with the help of an 'assembler/mapper' class).
Like I mentioned above, the web service has a dozen or so different
methods that operate on a business object (we have about a dozen
different types of items). Instead of having 144 different methods on
our web service, we only have 12. Albeit these web methods are just a
very thin layer on top of our buinsess facade before getting to the
domain business logic.
You raise a good point about exploring inheritance based schemas -
currently the schema that eventually translates into a DTO are all
individual even though the complex business objects that use them are
coming from a OOP heirarchy (the schemas just duplicate common
properties). Would then the web methods deal in the 'base' schema/
class? Then I assume the return types of that method would be of the
base DTO class. But would this be okay for non-.Net clients?
But given my current project realities, would returning the
representation of this DTO be best serverd by sticking the XML into a
string type or a different one?