Best way to handle the DataContext in LINQ to SQL

Question

I've gotten the go-ahead at work to implement LINQ to SQL for a new module in our ASP.NET app. I forget the best way to handle the DataContext required to retrieve objects; should I create it in every method that makes use of it, or have some kind of Utility class to manage it in a different fashion?

For instance, I have a class that ActiveRecord-style retrieves an entity. Should I be using something like:

using (MyAppDataContext context = new MyAppDataContext()) { // do stuff here... }

in each of these methods? I've seen this used frequently in the LINQ tutorials but I've also seen a way where there is a Utilities class that has some method that returns the DataContext (GetContext or similar); I forget if the method was just a wrapper around newing one up or if it did some kind of Singleton-type mechanism.

Which would be the better approach?

what is your app? web? wpf? it may matter... (but in either case, a singleton is probably a very bad idea - don't do that) — Marc Gravell
– Marc Gravell, Commented Jul 22, 2011 at 13:34
You don't want to hold a DataContext open. See Myth#10 albahari.com/nutshell/10linqmyths.aspx — asawyer
– asawyer, Commented Jul 22, 2011 at 13:39
@asawyer yes, but there is a middle ground between "per query" and "global"; for example, in a web app you might choose "per request", which would give a reasonable chance of "hits" from the identity manager, etc, without stale data or thread-safety becoming an issue — Marc Gravell
– Marc Gravell, Commented Jul 22, 2011 at 13:42

Stuart Blackler · Accepted Answer · 2011-07-22 14:41:05Z

Personally, I use something similar to this:

public class MyClass : MyBaseClass { public void GetData() { using(DbDataContext db = new DbDataContext()) { // DO STUFF } } public void PerformLogicallyAtomicAction() { using(DbDataContext db = new DbDataContext()) { // DO STUFF } } }

Unless there is any need to hold the data context open longer.

Update

To clarify a little bit more on the reasons why I do this:

1) I don't want an object in memory any longer than I need it

Below is the main reason

2) Tracking Change Data causes stale data in some cases (See 2nd comment on OP)

3) Creating the new object takes 0 time (effectively)

4) By creating it every time I need it, I can change specific LINQ options (EG. ObjectTrackingEnabled (which I frequently turn off)

Exchange "GetData" with "PerformLogicallyAtomicAction" and I'd agree. =)

Robb Sadler · Accepted Answer · 2011-07-22 14:16:25Z

I would use a class / object to contain the Methods you are using for this repository of data. I instance the datacontext with the class and then I can use it to read data and subsequently update it and stay in the same context.

I also use this class to centralize the connection string so that I have consistency across the entire application in accessing this particular data:

public class MyInfoRepository { MyInfoDataContext _dc; public MyInfoRepository() { try { _dc = new MyInfoDataContext(GetDbConnection()); } catch (Exception ex) { ExceptionLogger.LogServerException(ex, TraceEventType.Error); throw; } } private static string GetDbConnection() { // if no connection string return empty which will stop processing if (ConfigurationManager.ConnectionStrings["MyInfo"] == null) { throw new ConfigurationErrorsException("No connection string specified."); } string connection = ConfigurationManager.ConnectionStrings["MyInfo"].ConnectionString; return connection; } ...

As some of your comments stated, I would not keep this open, but use it for a particular query and update possibly with a using () statement.

Collectives™ on Stack Overflow

Best way to handle the DataContext in LINQ to SQL

2 Answers 2

1 Comment

Comments

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

1 Comment

Comments

Related