app design/architecture question

[Guest]

I have a 03 .NET web that does not use Typed DataSets, it uses a Busines
Layer/DataLayer classes. Alot of my reading on .NET 05 is using the DataSets
for the datalayer/business layer. I have a 05 web app that I used the
business/datalayer class architecture and it works. But my question is, what
is the recommended way in 05? DataSets or the 'Classes'?
Is there a best way or is it pretty much up to the developer on how to code
the applications?

I'm just looking to see the best way to use 05 for my future applications.
from time to develope to scalablity as well. thanks for any suggestions.

 

[Karl Seguin [MVP]]

The field is split pretty evenly down the line on this issue. It's true that
Microsoft promotes DataSets very heavily in their documentation and guides.
Personally, I think that's just very lazy. DataSets are easier and quicker,
a real domain model is more robust and maintainable - if you know what you
are doing.

It's like good N-Tier design, there's an initial upfront investment
(learning, training, experimenting...), but the payoff is great in the long
run - especially if you are workin on a typical enterprise application.

In the end, whatever you are more comfortable with and have a good
understanding of.

Karl

 

[Registered User]

I have a 03 .NET web that does not use Typed DataSets, it uses a Busines
Layer/DataLayer classes. Alot of my reading on .NET 05 is using the DataSets
for the datalayer/business layer. I have a 05 web app that I used the
business/datalayer class architecture and it works. But my question is, what
is the recommended way in 05? DataSets or the 'Classes'?
Is there a best way or is it pretty much up to the developer on how to code
the applications?

It really should not be a developer's decision since it is a design
question. That is OK because you forgot you're a designer at the
moment and not a programmer.

I'm just looking to see the best way to use 05 for my future applications.
from time to develope to scalablity as well. thanks for any suggestions.

Outstanding! Too many people spend too much time trying to design in
code rather than thought. There are many reasons why I prefer using
collections and arrays of objects to datasets.

A project I am working on involves auto parts. The part description
and other details come from a universal catalog server while the price
and availability comes from a specific store's server. Having a part
be two disparate datarows can only provide complications. At some
point in the future all the data will all come from a store's server
as a single resultset. How will this change effect the business and UI
layers?

If the UI and business layers are dealing with objects of type Part
instead of datasets the change will be invisible. The only question is
where does the transition from datarow(s) to Part object take place?
The purist in me doesn't want the business layer to know about generic
data objects or the data layer knowing about specific business types.
This is why I put a 'translation' layer between the data and business
layers. This methods of layer are very thin; they map arguments and
return values from data to business object and vice-versa.

UI ... Catalog <- parts -> CatalogProcs <- data -> CatalogDBProcs
<-SQL-> DB server

When where the data comes from changes, the same changes will have to
be made in the code no matter how many layers. With the extra layer
the business layer's code will not be changed at all. I see this as
very important; you can't break it if you don't change it.

Equally important is the pattern this design lays out. Store, Account
and User types are really no different than the Part type. The
specificity of an object makes everything so much easier.

This is my biased POV. Keeping thinking and write some simple
throw-away projects both ways. You'll start to see patterns, some
functionally better than others. Keep at it and you'll answer all your
own questions.

regards
A.G.

 

[sloan]

http://sholliday.spaces.live.com 6/5/2006 5/24/2006

At my blog, I have some downloads to compare the 2.

Also, at that entry, I reference this url:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp

Read that .. Top to Bottom. It gives a bird's eye view.
And talks about pros/cons of Strong Objects / Typed DataSets.

If its production code, I usually defer to the objects.

If its reports, I defer to typed DataSets.

If its my mom's favoriate plants site, then I go with typed datasets.

I usually call typed datasets the "poor mans' business object".

...