3-tier application with webservices, objectoriented? -- dotnet web services

dotnet web services : 3-tier application with webservices, objectoriented?

Christoph Schittko [MVP]
12/29/2004 1:38:10 PM

I don't have any good links, just my own opinions ;)

You're absolutely right. The DataSet is not object oriented, gets you up
and running fast and helps tremendously with DataBinding. For many
simple, data driven applications, that's an acceptable set of
trade-offs.

However, if you're looking at more complex apps then you're right about
asking for more. You have some data binding support in windows forms for
classes with properties, but unfortunately VS.NET and wsdl.exe don't
create such classes until the VS 2005 release. You can look at wscf [0]
to generate classes with properties instead of fields. In VS 2005 the
whole object-oriented aspect of data binging improves, but that probably
doesn't help you today.

With regards to where you're business logic should go, the answer is
always the same: In the services layer. Smart clients enable richer user
interaction, but that should be it. You are adding quite a bit of
maintenance liability if you deploy business logic to the client. That
logic should still remain on the middle tier, which is exposed through
the service layer.

Now, you as the designer have to decide how complex your business logic
is and what the benefits of OO are to your application and then if those
benefits are worth losing the benefits of weak typing and DataSets.
Generally, I am very much for strongly typed service interfaces, which
DataSets do not provide. You may want to look at typed datasets as some
form of compromise.

HTH,
Christoph Schittko
MVP XML
http://weblogs.asp.net/cschittko

[0]
http://www.thinktecture.com/Resources/Software/WSContractFirst/default.h
tml

[quoted text, click to view]

nixon
12/29/2004 8:12:54 PM

Hi there!
Im trying to build a 3 tier application that uses a smartclient in the
"view" layer.
The communication between the smartclient and the server should be
webservices because of potentiel firewall issues.
I´ve looke at to smartclient demos to figure out how the experts do the
stuff, design and overall architecture, Microsofts IssueVision and
TaskVision.

These applications uses DataSet´s to communicate between the layers and
binds these Dataset´s directly to the UI. The approach seems to get you "up
and running" very fast. However, from my point of view, thisapproach is not
very "objectoriented". No Businessobjects encapsulating business rules and
so on.
I´m not trying to start a religious discussion about objectorientation vs.
proc. programming, I just don´t get it!
In my application we have tons of business rules and transformation of data,
where should we put this logic if we go for an design like the demos
mentioned above?

I could define and instantiate my custom Business objects on the client that
were instantiated from a DataSet (the dataset is returned from som
webservice). However, in this kind of approach i loose all the benefits from
the DataSet in e.g.

- ease of Binding to win controls
- synchronisatzion with the server, update, delete etc.

Do you have any good advices or links to articles demos?
Thanks!

Best regards niclas

nixon
12/29/2004 9:21:51 PM

Hi Christoph and thank´s for your fast reply!
As you say yourself, future realease of the framework doesn´t help me here
and now, we need to find a solution right away :-)
I totally agree of putting the Business logic in the Servicel ayer, even
though I am not quite sure how to put it into practice at the moment.
I can´t see how I could avoid not duplicating business logic / code even in
a service layer approach, many of my businessrules / logic must reside in
the client layer as in the Service layer, my maintainability goes away.

Maybe I could define my Business classes with a DAO pattern, depending on
which layer a Business class is operating in (Client or Service layer) it
would have different DAO objects / implementations to persist them. The DAO
for the client business object persists the object via my Service layers
exposed webservices, uses maybe a DataSet as a value object.. The Service
layer representation of the business object uses another DAO, a object that
uses classes of the System.Data namespace to finally persist the business
object.

Or..... should i just go for the plain "simple" strongly typed Dataset
approach????

Best regards Niclas
[quoted text, click to view]

Sami Vaaraniemi
12/30/2004 9:43:37 AM

I agree with what Christoph wrote. Here's what I use as guidelines when I
choose between DataSets and an OO approach:

- If there are no interoperability requirements, and the data is needed for
display and reporting purposes, then a DataSet or a typed DataSet is fine.
If you use classes and objects when you don't really need them, then you are
paying a price without actually gaining anything.
- If there are interoperability requirements, then e.g., an array of simple
data objects is better suited than a DataSet.
- If there is non-trivial business logic involved, then a business object
class hierarchy could be the best approach. In some cases using a typed
DataSet might be a good enough an approach.

I know that this sounds pretty much like 'use objects if you benefit from
them, otherwise don't use'. But that's the way software design often goes.
There is no silver bullet that would work in every situation.

Regards,
Sami

[quoted text, click to view]

Radek Cerny
12/30/2004 12:18:58 PM

I know exactly where you're at. Its a bit "out there", but have a read of
http://www.asplications.com.au/GenieWhitePaper.pdf. It deploys business
systems as web services, accessible from Winforms, javascript/dhtml, compact
framework clients etc., anything that consumes Web Services. And not a
DataSet to be found anywhere...

[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages about dotnet web services

home · blog · groups

Questions? Comments? Contact the dn