Prev: How to prevent focus outlining on buttons
Next: How do I know I am in a debug configuration
From: Paul on 26 Mar 2010 06:08
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
From: not_a_commie on 26 Mar 2010 11:15
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.
From: Gregory A. Beamer on 26 Mar 2010 11:50


"Paul" <gambamia2(a)yahoo.es> wrote in message
news:d1870a6d-8a31-4003-b356-cdf7d020d4e0(a)x12g2000yqx.googlegroups.com...
> 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?

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! |
************************************************

From: Patrice on 26 Mar 2010 12:52
They both keep changes in memory. Those changes are committed to the
database when you'll ask for this (DataContext.SubmitChanges)...

If you are looking for a data access API it could be better to compare
between datasets and Entity Framework (which is quite similar to Linq to Sql
which is SQL Server, handles less mapping capabilities and will likely be
superseded by EF).

--
Patrice


"Paul" <gambamia2(a)yahoo.es> a �crit dans le message de groupe de discussion
: d1870a6d-8a31-4003-b356-cdf7d020d4e0(a)x12g2000yqx.googlegroups.com...
> 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


From: Mr. Arnold on 26 Mar 2010 14:58


"Gregory A. Beamer" wrote:

> 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.
>

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.
 |  Next  |  Last
Pages: 1 2
Prev: How to prevent focus outlining on buttons
Next: How do I know I am in a debug configuration