LINQ or DataSet?

[Frederik]

Hi all,

Am I correct when stating that LINQ replaces somewhat DataTables?

I have done some reading concerning LINQ, but I'm still puzzled as to
whether I should use LINQ or not. My application imports data from an
XML file and stores the data in a DataSet (with 3 DataTables in it).
The DataTables are used to fill several DataGridViews (via DataViews/
BindingSources). When the user saves his changes, the DataTables are
used to rebuild the xml file.

My data is stored hierarchical (via relations and constraints between
the DataTables), so suited for LINQ? Would it be an advantage in using
LINQ to perform this and leave the DataSet/DataTables behind? Will
performance gain? Sorry for maybe asking some stupid questions, but I
need to understand this LINQ thing before I move on with my
application.

Thanks in advance for your help,
Fre

 

[Barry Kelly]

Am I correct when stating that LINQ replaces somewhat DataTables?

Not really. LINQ constructs data pipelines, while DataTables are buckets
of data.

I have done some reading concerning LINQ, but I'm still puzzled as to
whether I should use LINQ or not. My application imports data from an
XML file and stores the data in a DataSet (with 3 DataTables in it).
The DataTables are used to fill several DataGridViews (via DataViews/
BindingSources). When the user saves his changes, the DataTables are
used to rebuild the xml file.

My data is stored hierarchical (via relations and constraints between
the DataTables), so suited for LINQ? Would it be an advantage in using
LINQ to perform this and leave the DataSet/DataTables behind? Will
performance gain? Sorry for maybe asking some stupid questions, but I
need to understand this LINQ thing before I move on with my
application.

Anything you use LINQ with basically constructs an IEnumerable<T>
implementation instance that you can iterate over in a forward-only
fashion, or pass as an argument to something that takes IEnumerable<T>,
or bind to a UI control (which can work with IEnumerable<T>), etc.

If you can solve your problem in a forward-only fashion through an
IEnumerable<T> list, then you may be in luck. Otherwise, you'll need to
do more work - however, you might still use LINQ to source your data,
modify your data in a streaming fashion, or transform your data into an
output object model like System.Xml.Linq's object model, or all three.

Look at the LINQ to XML guide in the MSDN library for examples of what
you might use LINQ for.

-- Barry

 

[Arne Vajhøj]

Am I correct when stating that LINQ replaces somewhat DataTables?

LINQ for SQL contains an O/R mapper.

If you want an object oriented model in memory for your
data even though they are in an relational database
on disk then LINQ is one way to go (there are other
O/R mappers like NHibernate and LLBLGen).

If you want a relational model in memory then DataSet
is the way to go.

The bigger the project the more attractive the object oriented
model will be.

Arne