better way of using XML

[Sharon]

hi all

I have a small application assembled from

C# winForm client side (few of them)

C# webService at the server side



I'm using xml file to transfer the GUI information from client to server

For Example in the client window there are 3 text box's and one button

Text boxes are "first num" , " second num" and "sum"

And "calc" button



So when the user click the "calc" button , the winForm window send the GUI
xml to the server , and the server parses the xml file and fill in the
records

Xml example :

<Gui_items>

<item>

<textbox name="first
num">30</textbox>

</item>

<item>

<textbox name="second
num">50</textbox>

</item>

<item>

<textbox
name="sum"></textbox>

</item>

</Gui_items>



the server response will be :



<Gui_items>

<item>

<textbox name="first
num">30</textbox>

</item>

<item>

<textbox name="second
num">50</textbox>

</item>

<item>

<textbox
name="sum">80</textbox>

</item>

</Gui_items>



Then the winForm client get the response XML and parses it ,

All GUI item's are filed in to the GUI controls



This only simple example, the real client window is much complex,

I'm using labels and label's color changing



Currently I'm parsing the XML file using System.Xml

Is there any way I can bind the GUI elements to this XML and make it easier
for me to develop it ?

Is there any way I can use dataset's and have the same goal ?



Please post any comment you have



Thank you very much

Sharon

 

[Kevin Spencer]

Hi Sharon,

I think you need to separate in your mind the GUI and the data that it
represents. The only data going to the Web Service should be business data.
The GUI can manage itself, and the Web Service doesn't have to know anything
about the GUI, only the data that it represents. Remember that the "U" in
GUI is "User," meaning that the GUI is for a human user, not for a business
class.

The GUI is supposedly getting its data from some sort of business layer of
business objects that actually do the work with the data, or it should be.
This type of layered design makes it easier to port from one sort of
interface to another (such as a Windows form to an ASP.Net app or a Console
App, for example). The GUI's job is to present data to a User, and to
receive input from the User.

As for the Web Service, it should be a set of SOAP Web Methods that are,
essentially, business methods. That is, these methods operate only on data,
receiving it, retrieving it, and manipulating it. It is possible, for
example, to create an application whose business classes are entirely Web
Services. The GUI simply talks to the Web Service by calling Web Methods, as
if it were talking to a local set of business objects and making method
calls to them.

This separation enables each logical "layer" to manage the business that is
its own, without any other layer having to know anything about that layer's
"personal" business. Or, as my Uncle Chutney sez, "a class should mind its
own business."

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but you can't make it stink.

 

[Guest]

Why don't you just create a serializable "UIState" class that you send to the
webservice via a Webmethod, and it sends you something similar back?
Then all you have to do is read the properties on the response class and do
whatever they say to your UI (Colors, values, etc).
Then you can set a WebReference to your WebService and you don't have to
parse any XML at all.
Peter