What is better, use DataContext or dataset

  • Thread starter Thread starter Paul
  • Start date Start date
P

Paul

Hi,
It seems that the DataContext is not allowed to work in memory and
insert all changes made to the database until the end.
I think to work in memory dataset is better, right?

Thanks
 
Explain what you mean by work in memory. Are you talking about the
SQLite memory database? I can't think of any good reason to use
Dataset over the much newer and much improved DataContext.
 
Paul said:
Hi,
It seems that the DataContext is not allowed to work in memory and
insert all changes made to the database until the end.
I think to work in memory dataset is better, right?
Click to expand...

Let's make sure we are understanding that DataSets and contexts are not
corollaries. LINQ objects and a DataSet correlate to an extent, but a
DataContext does not.

As for what is better to use? I would say DataSet with a TableAdapter, if
you gave me these choices. But I find LINQ to SQL to be so anemic that it is
a worthless technology for most of the applications I work on. I love LINQ,
as LINQ, but as soon as you start using it for data access, you are trading
a good abstraction for very poor performance. Note that I am dealing more in
the Enterprise space. If you are dealing with small business and personal
sites, you might find LINQ to SQL will work for you.

I would be more inclined to look at EF (which can be used with LINQ in the
middle tier) or even custom models with a Repository pattern.

NOTE: DataSets, while a bit heavy, actually work rather nicely and decouple
the access from the model. I am not against them, if you are familiar with
them. I suggest you reduce any perf penalty by using strongly typed
DataSets, of course. This is not my preference, as I like thinner models,
but it works. And, I have used them in organizations that are very used to
DataSets.

Hope this helps!

--
Peace and Grace,
Greg

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

************************************************
| Think outside the box! |
************************************************
 
Gregory A. Beamer said:
I would be more inclined to look at EF (which can be used with LINQ in the
middle tier) or even custom models with a Repository pattern.
Click to expand...

Yes, this is the direction to go EF becuase it's an Enterprise solution.
We're using EF in the back-end of WCF Web service with BLL, DAL and EF model.

The new boy on the block that I want to get a hold of is WCF RIA services
using EF and DomainDataSource.
 
The new boy on the block that I want to get a hold of is WCF RIA services
using EF and DomainDataSource.
Click to expand...

I've used ria.net.
Hopefully wcf ria will be better.
 
Yes, this is the direction to go EF becuase it's an Enterprise solution.
Click to expand...

I agree that EF is the way to go.

But I will note that "Enterprise" typical just means expensive.

Arne
 
It seems that the DataContext is not allowed to work in memory and
insert all changes made to the database until the end.
I think to work in memory dataset is better, right?
Click to expand...

I would avoid DataSet.

If you need something primitive the use Command & Reader.

If you need something advanced, then use an ORM.

If one ORM does not provide what you need then find
another one. There are multiple to chose from.

In general you should go for LINQ to EF not LINQ to SQL.
LINQ to EF seems to be what MS will evolve moving forward.

Arne
 
Back
Top