469,898 Members | 1,611 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,898 developers. It's quick & easy.

Traditional Collections and Objects or Typed Datasets ?

Hi,

I've been tasked to come up with a new architecture for a large
application at one of my customer's sites.

In the past, I have developed multi-tier applications whereby the
business objects maintain the database using stored procedures etc and
provide the data to the GUI layer via a set of objects and collections.
After using the typed datasets with .NET, it appears that you van
provide the same functionality as objects and collections with the
datasets - for a lot less coding effort.

My question is - is the general idea to move away from objects and
collections and into these typed datasets ?

Thanks,
Rob
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 17 '05 #1
3 1556
PJ
I personally believe that you will never get the long term flexibility
inherent in creating classes that represent your business problem as opposed
to limiting yourself to out of the box classes provided by a framework.

My statement might be a little misleading though. You will always have
classes that you create; indeed when you add your first web page, you have
your first class. Additionally, you will always use classes provided by the
framework to a large extent. For the purpose of your question, my opinion
is on how to best represent the state of your business data. There is a
definate speed of development advantage to simply using datasets and
marshalling data between layers of your application as such. As the
application grows, I believe you will see an object oriented as well as a
performance advantage to creating custom classes to represent your data
specific to your business need. You may still use
datasets/datareaders/xmldocuments to hydrate your custom classes.
Additionally, as you get more experienced with this approach, the rapid
development advantage of solely using framework classes to represent your
data will begin to diminish.

Datasets were designed to hold in memory data for any type of data. This
can never be as flexible/robust as a custom class you have built to
represent an entity or process specific to your business need.
"Rob Thomas" <ro*@rtcomputersystems.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
Hi,

I've been tasked to come up with a new architecture for a large
application at one of my customer's sites.

In the past, I have developed multi-tier applications whereby the
business objects maintain the database using stored procedures etc and
provide the data to the GUI layer via a set of objects and collections.
After using the typed datasets with .NET, it appears that you van
provide the same functionality as objects and collections with the
datasets - for a lot less coding effort.

My question is - is the general idea to move away from objects and
collections and into these typed datasets ?

Thanks,
Rob
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Nov 17 '05 #2
Thanks for the advice guys, it's much appreciated.

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 17 '05 #3
PJ
take a look here as well:
http://msdn.microsoft.com/practices/...ns/enterprise/

"Rob Thomas" <ro*@rtcomputersystems.com> wrote in message
news:uj**************@TK2MSFTNGP10.phx.gbl...
Thanks for the advice guys, it's much appreciated.

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Nov 17 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

25 posts views Thread by Stuart Hilditch | last post: by
7 posts views Thread by rodchar | last post: by
25 posts views Thread by Penelope Dramas | last post: by
12 posts views Thread by BillE | last post: by
reply views Thread by Salome Sato | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.