Re: typed datasets vs. business objects


"Mr. Arnold" <MR. Arnold@xxxxxxxxxx> wrote in message
news:e74Lqq8rIHA.3940@xxxxxxxxxxxxxxxxxxxxxxx

"John Sheppard" <spam@xxxxxxxxxx> wrote in message
news:fvod2d021e3@xxxxxxxxxxxxxxxxxxxx

"Mr. Arnold" <MR. Arnold@xxxxxxxxxx> wrote in message
news:eT$QieErIHA.3616@xxxxxxxxxxxxxxxxxxxxxxx

"John Sheppard" <spam@xxxxxxxxxx> wrote in message
news:fvealh02tb6@xxxxxxxxxxxxxxxxxxxx

"BillE" <belgie@xxxxxxxxxxx> wrote in message
news:O1lDq%238qIHA.4912@xxxxxxxxxxxxxxxxxxxxxxx
I'm trying to decide if it is better to use typed datasets or business
objects, so I would appreciate any thoughts from someone with more
experience.

When I use a business object to populate a gridview, for example, I
loop through a datareader, populating an array list with instances of
a custom class in the middle tier, and then send the array list up to
the presentation layer and bind the gridview to it.

If I use a typed dataset, I just fill it with a data adapter and then
bind it to the gridview.

It seems like the typed dataset would be more efficient, because I
don't have to loop through anything. But typed datasets are
aggravating, because it seems like they have to be defined all the way
down at the data access layer to be accessible in a n-tier solution.
They clutter up my solution.

Business objects seem tidier, and seem more professional, but are they
as efficient, with all the looping required?

Thanks
Bill


Im sure behind the scenes datasets loop through things
anyway....besides thats what computers do, they loop...I wouldnt worry
to much about that...

I'm by no means a guru. As I have only really experienced datasets, but
I have done lots and lots and lots of reading on them vs custom
objects. All my research can pretty much be sumed up with the following
; Datasets are excellent for small projects but large and/or
complicated projects they just keep you hemmed in....so for big project
it's worth the setup of custom objects.

My current project is based on datasets and its groovy in some regards,
but its going to become a real pain in the *** later down the track.

The amount of work I have done to just get my datasets generated has
been too much....Draggin and dropping stuff on to xsd every time the DB
changes....ugg...so im trying to generate them and its no easy
task.....I wish we had of gone custom business objects...but then I
havent been there so I cant tell you....but thats where everything
points...

I like neat also....it means quicker more readable code...its worth
alot...datasets are by no means neat :(

Why does this person need a custom business object in an Arraylist of
objects in the case of binding data to a control? If the dataset is
being used in a forward only manner, then simply binding the dataset to
the control is a much cleaner and faster solution.

And I beg to differ with you about a dataset being used in big projects.
I worked at a client site that used an in-house written object code
generator that pointed to SQL based on using stored procedures only, and
everything was generated using datatables and datasets in the DAL. The
DAL was used by Windows Desktop, Windows Service and Web applications,
which was also used in large projects.


Thats exactly what we are doing...its taken me many weeks develop that
inhouse dal. I think it woulda been much quicker to use an orm of some
kind that generates the custom objects.

It took me all of 10 minutes to complete any code in the DAL using
datasets and datatables. The in-house written code generator created the
DAL objects that the in-house written database engine used. What I mean is
someone wrote the code to access SQL Server tables to create the primitive
field types, etc, etc. Someone wrote the (DLL) code for the database
engine that was inplemented in each DAL object. In other words, it was
short of an ORM application that was in-house written and worked well.


I am out of my league here tho, I should not have spoken so confidently
:S

A dataset is just a representation of data in memory. That's all it is,
and datasets used in a DAL is just as fast and a viable solution than
using custom objects at the DAL that are not using datasets and
datatables, which one could still customize the code of the DAL that
used the DAL database engine.


Yeah, I guess I meant to say that just because he isnt writing the
looping code doesnt mean there isnt any there.

It's a mistake using datasets and datatables in the UI in your example
above. The database access should have been extracted from the UI so
that one doesn't face the problems that you are facing or will face for
large projects.

What would you bind to if there was no datasets to use at the UI level?

The mistake is if you are making direct calls from the UI to the database.
If you are going through UI-BL-DAL, that's not a problem. Direct database
access should be extracted from the UI.

ahh ic...yeah nah thats how we are doing it...UI-BL-DAL..


At current we just have one massive dataset which I use bindingsources to
attach to on the UI...


Really? That's kind of ugly. But it's all in one dataset in memory. What
happens when you have to update or insert records into a database?


Its ugly :) Very ugly...somewhere along the line I'd imagine I will be
forced to break it up, but for now it works well enough.

To persist it to the database I just loop through the dataset using
getchanges and execute an autogenerated sql statement for each one thats had
a change. It's not exactly efficient but it's working so far although I
*suspect* I will start having problems somewhere down the line...

It's on a webservice which complicated things, but getting all that stuff
working took me mroe time than I would have liked and I just figured I would
have been better off just paying for an ORM.

I guess put it this way; I don't feel 100% confident that im not going to
run into problems with my dataset architecture. I feel more confident with
an orm and custom objects because thats what seems to be what most blogs
live and die by, so I figure there must be a reason :)

Regards
John



.

Quantcast