L
Luqman
Is it recommended to use datasets in ASP.Net 2.0 / VS.Net 2005 ?
Best Regards,
Luqman
Best Regards,
Luqman
E
eguworks
Hello Luqman,
if you are interested in -just- reading data from whatever database,
you might want to take a look at the 'datareader', as it is more
effecient than the dataset.
Ofcourse if you wish to CRUD with data a dataset will do just fine.
also, you might want to take a look at the new datasource controls
available in asp.net 2.0, these too can do alot of work for you.
Egu
if you are interested in -just- reading data from whatever database,
you might want to take a look at the 'datareader', as it is more
effecient than the dataset.
Ofcourse if you wish to CRUD with data a dataset will do just fine.
also, you might want to take a look at the new datasource controls
available in asp.net 2.0, these too can do alot of work for you.
Egu
K
Kevin Spencer
Only if you need them.
--
HTH,
Kevin Spencer
Microsoft MVP
Professional Numbskull
Show me your certification without works,
and I'll show my certification
*by* my works.
--
HTH,
Kevin Spencer
Microsoft MVP
Professional Numbskull
Show me your certification without works,
and I'll show my certification
*by* my works.
E
Eliyahu Goldin
Datasets are principal building blocks for business logic in dotnet.
Consider using them in all cases where you care about business logic.
Eliyahu
Consider using them in all cases where you care about business logic.
Eliyahu
M
Mark Rae
M
Mark Rae
Yes, particularly if you're working with databases... ;-)
K
Karl Seguin [MVP]
I disagree. datasets are bloated and break from traditional OO practices.
It's possible to build a solid domain layer around datasets, but requires
extra discipline and care.
It's an ongoing debate which developers should familiarize themeselves with
deeply:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/CustEntCls.asp
http://scottonwriting.net/sowblog/posts/3867.aspx
Karl
It's possible to build a solid domain layer around datasets, but requires
extra discipline and care.
It's an ongoing debate which developers should familiarize themeselves with
deeply:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/CustEntCls.asp
http://scottonwriting.net/sowblog/posts/3867.aspx
Karl
K
Karl Seguin [MVP]
objects and classes are the principal building blocks for business logic in
..NET. A DataSet is merely an existing generic container for this - one that
many would say it's drawbacks far outweigh it's
benefits.
Karl
..NET. A DataSet is merely an existing generic container for this - one that
many would say it's drawbacks far outweigh it's
benefits.
Karl
I
Ing. Davide Piras
From my point of view,
when your business logic layer is very thin and you just need to forward
insert, update and select operations to the datalayer then you can use
datasets (typed or not but I like to put all my typed dataset in another
layer which I call commonlayer), of course if your application requires a
more complex business logic it could happen that dataset are not enough so
you can still use them for data transfers, but probably you will need
objects (class definitions) to "envelope" your process logic...
anyway you can heaven inherit from dataset and add your own methods and
properties...
Davide.
when your business logic layer is very thin and you just need to forward
insert, update and select operations to the datalayer then you can use
datasets (typed or not but I like to put all my typed dataset in another
layer which I call commonlayer), of course if your application requires a
more complex business logic it could happen that dataset are not enough so
you can still use them for data transfers, but probably you will need
objects (class definitions) to "envelope" your process logic...
anyway you can heaven inherit from dataset and add your own methods and
properties...
Davide.
E
Eliyahu Goldin
Objects and classes are too general notions. Datasets come with strong
typing and design tools that do good job for you. Again, they are good when
you care about business logic. When you don't, when all you need is just to
provide data to your form, then they are indeed too heavy.
Eliyahu
"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net> wrote in message news:%[email protected]...
typing and design tools that do good job for you. Again, they are good when
you care about business logic. When you don't, when all you need is just to
provide data to your form, then they are indeed too heavy.
Eliyahu
"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net> wrote in message news:%[email protected]...
K
Kevin Spencer
Well, now, I wouldn't say that is set in stone. There are situations where
DataSets are completely appropriate, although I imagine they arise less
often in ASP.Net applications. For example, I'm currently working with a
Windows Forms app that interacts with a half-dozen tables in the same
database. It is a multi-user app, and as it requires navigating among the
tables with a lot of freedom, I'm using a strongly-typed DataSet, a number
of strongly-typed DataTables, BindingSources, and custom controls based on
the DataGridView. For this project, I found DataSets very useful. But I must
also admit that it is the first app I have worked on in which I found them
useful.
IOW, always use the best tool for the job. And of course, the only way to
know the answer to that one is to be familiar with all of the available
tools.
--
HTH,
Kevin Spencer
Microsoft MVP
Professional Numbskull
Show me your certification without works,
and I'll show my certification
*by* my works.
"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net> wrote in message news:[email protected]...
DataSets are completely appropriate, although I imagine they arise less
often in ASP.Net applications. For example, I'm currently working with a
Windows Forms app that interacts with a half-dozen tables in the same
database. It is a multi-user app, and as it requires navigating among the
tables with a lot of freedom, I'm using a strongly-typed DataSet, a number
of strongly-typed DataTables, BindingSources, and custom controls based on
the DataGridView. For this project, I found DataSets very useful. But I must
also admit that it is the first app I have worked on in which I found them
useful.
IOW, always use the best tool for the job. And of course, the only way to
know the answer to that one is to be familiar with all of the available
tools.
--
HTH,
Kevin Spencer
Microsoft MVP
Professional Numbskull
Show me your certification without works,
and I'll show my certification
*by* my works.
"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net> wrote in message news:[email protected]...
J
Joerg Jooss
Thus wrote Eliyahu,
Um... DataSets and *business logic*? Well, if you really like the active
record pattern...
Um... DataSets and *business logic*? Well, if you really like the active
record pattern...
F
Flinky Wisty Pomm
Just my 2 cents - I've only used DataSets for the rare case when I want
to grab a chunk of my database complete with relations, usually for
fairly convoluted reports where no immediately intuitive business
object mapping. I think that's happened once so far
Other than that, it's been SqlDataReaders and business objects all the
way, and as I start to grok OO I'm becoming more and more of a purist
about separating my data layer from the UI. Most of the drag 'n drool
features of ASP.Net are fine until you come to build something complex,
or anything that's going to take a beating from a volume of users.
If you genuinely care about business logic, put it in a business logic
layer, keep your data layer for retrieving data, and your UI for
displaying and playing with it. All kinds of nice little benefits arise
unexpectedly from well-factored code.
</lecture>
to grab a chunk of my database complete with relations, usually for
fairly convoluted reports where no immediately intuitive business
object mapping. I think that's happened once so far
Other than that, it's been SqlDataReaders and business objects all the
way, and as I start to grok OO I'm becoming more and more of a purist
about separating my data layer from the UI. Most of the drag 'n drool
features of ASP.Net are fine until you come to build something complex,
or anything that's going to take a beating from a volume of users.
If you genuinely care about business logic, put it in a business logic
layer, keep your data layer for retrieving data, and your UI for
displaying and playing with it. All kinds of nice little benefits arise
unexpectedly from well-factored code.
</lecture>
K
Karl Seguin [MVP]
Agreed with everything.
DataSets have extra benefits in WinForms that outweighs a number of the
shortfalls.
It depends on what you are trying to do. And rather than having people
explain to me what they are trying to do, it's better for them to learn the
pros and cons and apply it to their problems But since there tends to be
an overwhelming pro-DataSet support in ASP.NET, I like to counter-balance as
strongly as possible
Karl
--
http://www.openmymind.net/
http://www.fuelindustries.com/
DataSets have extra benefits in WinForms that outweighs a number of the
shortfalls.
It depends on what you are trying to do. And rather than having people
explain to me what they are trying to do, it's better for them to learn the
pros and cons and apply it to their problems
But since there tends to bean overwhelming pro-DataSet support in ASP.NET, I like to counter-balance as
strongly as possible
Karl
--
http://www.openmymind.net/
http://www.fuelindustries.com/
Kevin Spencer said:
S
Steve C. Orr [MVP, MCSD]
It takes time to instantiate and fill a DataSet just to throw it away in a
few milliseconds when the page is done rendering.
Therefore, generally DataReaders are a more efficient solution in ASP.NET.
However, if you need to do some extra fancy data manipulation then there are
times when a DataSet would be a better choice.
One good use for DataSets in ASP.NET is when you need to cache some data.
DataReaders can't really be cached so a DataSet (or better yet a DataTable)
is a good choice in this situation.
few milliseconds when the page is done rendering.
Therefore, generally DataReaders are a more efficient solution in ASP.NET.
However, if you need to do some extra fancy data manipulation then there are
times when a DataSet would be a better choice.
One good use for DataSets in ASP.NET is when you need to cache some data.
DataReaders can't really be cached so a DataSet (or better yet a DataTable)
is a good choice in this situation.
K
Kevin Spencer
But since there tends to be an overwhelming pro-DataSet support in
I'm 100% with you there, Karl. Many people use DataSets because they are
"easier" to use than hand-rolled data code. That is, they have a lot of
built-in functionality, and GUI tools to support them. This is absolutely
the *wrong* reason to use any resource in an application. Requirements alone
should dictate the tools used to write an application.
DataSets are disconnected. This can be useful, and it can also bite one in
the *ss, if one does not plan for it. In an ASP.Net application, caching a
large DataSet can be a memory issue. An ASP.Net application is a
client-server application. Memory and processor must be managed well.
IOW, laziness and ignorance are both inexcusable, as they are both by
choice. In addition, laziness in programming has the ultimate and ironic
effect of causing *more* work over the long haul. It is important to
understand one's motivations for using various tools in the toolset.
--
HTH,
Kevin Spencer
Microsoft MVP
Professional Numbskull
Show me your certification without works,
and I'll show my certification
*by* my works.
"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net> wrote in message news:[email protected]...
ASP.NET, I like to counter-balance as strongly as possible
I'm 100% with you there, Karl. Many people use DataSets because they are
"easier" to use than hand-rolled data code. That is, they have a lot of
built-in functionality, and GUI tools to support them. This is absolutely
the *wrong* reason to use any resource in an application. Requirements alone
should dictate the tools used to write an application.
DataSets are disconnected. This can be useful, and it can also bite one in
the *ss, if one does not plan for it. In an ASP.Net application, caching a
large DataSet can be a memory issue. An ASP.Net application is a
client-server application. Memory and processor must be managed well.
IOW, laziness and ignorance are both inexcusable, as they are both by
choice. In addition, laziness in programming has the ultimate and ironic
effect of causing *more* work over the long haul. It is important to
understand one's motivations for using various tools in the toolset.
--
HTH,
Kevin Spencer
Microsoft MVP
Professional Numbskull
Show me your certification without works,
and I'll show my certification
*by* my works.
"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net> wrote in message news:[email protected]...
F
Flinky Wisty Pomm
Steve said:
If I can just hijack this thead a bit... I've been meaning to ask for a
while; how well do business objects cache? I've got a few places in the
current app where we keep static chunks of data lying about, sometimes
in custom collections, more commonly in generic dictionaries; but I'm
considering setting up a DAL in a future project where most data will
be cached, quite possibly in an OrderedBag from the PowerCollections
code.
It would mean I could page/sort/filter my strongly typed objects, and
generally do all sorts of wonderful Object Oriented Ajax-y things
without cluttering StoredProc code or gulping thousands of rows for
each postback, but I'm terrified whenever I start thinking about how
much RAM it's going to consume. We've got two managed servers, and more
servers can be added but I'm wondering just how inefficient this is.
Any comments?