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

the

and

you

vs.

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

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