Kind of an open question on best-practice for smart-client design. I'd
really appreciate anyones views (preferably with reasoning, but I'll take
what I get...). Or if anybody has any useful links on the subject? (and yes,
I have already googled it at length, but still no strong decision)
=============
After a long stint of pure-desktop / pure-server applications, I'm currently
working on a number of smart-client projects in C# using .Net 2.0.
Obviously we need to do our data access through the web-service, but we have
various options available to us, including:
* Define rich classes at the server (exposed directly as e.g. the return
value from [WebMethod] functions), then use WSDL.exe to extract a
representation of those objects to use at the client
* Using datasets
* Using a hand-crafted, documented schema (presumably xml) on the
web-service and manually constructing (separate) rich objects at both ends
* Not using objects on the web-service, but simpler "parameter-per-property"
based invokes
* Others
Personally I favor the first object, as it
a: best fits my (pre-conceived? naive?) ideas of OO
b: doesn't bind the client and server too closely together (i.e. I could
probably call the web-service from a VB6 or Java client if I wanted - no
dependency on the more complex dataset object, and no dependency on a .Net
client (as would exist if I did binary serialization))
c: seems reasonably efficient code-wise, as I don't need to write all my own
code to stub out the client objects and web-service methods (WSDL.exe does
that for me)
d: allows me to pass complex data in a single round-trip to the server,
rather than multiple calls which would then need more complex transaction
management
e: thanks to the BindingSource and the flag to WSDL.exe that enables
INotifyProperty Changed, meets all of my UI data-binding needs
f: avoids messing with datasets, which (maybe incorrectly) I percieve as
slightly messy and less efficient that performing my own database access at
the server
OK, this means that at the client I have objects with reduced functionality
(arrays instead of object-collections), but in the few cases where I
genuinely need something more sophisticated I can always wrap it in a facade
or other wrapper, so no huge issue here.
---
So - before I go to town, am I barking up the wrong tree? Am I making my
life hard for the future, or is this a reasonable approach? I don't have any
immensely complex/specialized requirements, so it should be similar to other
peoples experiences...?
All thoughts appreciated.
Marc
really appreciate anyones views (preferably with reasoning, but I'll take
what I get...). Or if anybody has any useful links on the subject? (and yes,
I have already googled it at length, but still no strong decision)
=============
After a long stint of pure-desktop / pure-server applications, I'm currently
working on a number of smart-client projects in C# using .Net 2.0.
Obviously we need to do our data access through the web-service, but we have
various options available to us, including:
* Define rich classes at the server (exposed directly as e.g. the return
value from [WebMethod] functions), then use WSDL.exe to extract a
representation of those objects to use at the client
* Using datasets
* Using a hand-crafted, documented schema (presumably xml) on the
web-service and manually constructing (separate) rich objects at both ends
* Not using objects on the web-service, but simpler "parameter-per-property"
based invokes
* Others
Personally I favor the first object, as it
a: best fits my (pre-conceived? naive?) ideas of OO
b: doesn't bind the client and server too closely together (i.e. I could
probably call the web-service from a VB6 or Java client if I wanted - no
dependency on the more complex dataset object, and no dependency on a .Net
client (as would exist if I did binary serialization))
c: seems reasonably efficient code-wise, as I don't need to write all my own
code to stub out the client objects and web-service methods (WSDL.exe does
that for me)
d: allows me to pass complex data in a single round-trip to the server,
rather than multiple calls which would then need more complex transaction
management
e: thanks to the BindingSource and the flag to WSDL.exe that enables
INotifyProperty Changed, meets all of my UI data-binding needs
f: avoids messing with datasets, which (maybe incorrectly) I percieve as
slightly messy and less efficient that performing my own database access at
the server
OK, this means that at the client I have objects with reduced functionality
(arrays instead of object-collections), but in the few cases where I
genuinely need something more sophisticated I can always wrap it in a facade
or other wrapper, so no huge issue here.
---
So - before I go to town, am I barking up the wrong tree? Am I making my
life hard for the future, or is this a reasonable approach? I don't have any
immensely complex/specialized requirements, so it should be similar to other
peoples experiences...?
All thoughts appreciated.
Marc
Comment