2
public class CommonService
{
    private readonly DataContext _context;

    public CommonRepository()
    {
        _context = new DataContext();
    }

    public CommonRepository(DataContext context)
    {
        _context = context;
    }

    public List GetAll()
    {
        var query = from m in _context.MyModel
                    select m;
        return m.ToList();
    }
}

or


    public class CommonService
    {
        public List GetAll()
        {
            using (DataContext context = new DataContext())
            {
                var query = from m in context.MyModel
                            select m;
                return m.ToList();
            }
        }
    }

or you have more pattern, suggest me please.

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Wut Karin
  • 31
  • 1
  • 2
    Note that your question is: "Should I use/allow *dependency injection* in my code that happen to use LINQ?" - answer: **yes**... Please clarify what kind of advice you are looking for. – Alexei Levenkov Feb 04 '14 at 02:55
  • 1
    @AlexeiLevenkov, that's true, but as you've noted, it's hard to assess without knowing the lifetime behavior of `CommonService`. If it's in any way a singleton, a permanent data context would be a very bad idea. – Kirk Woll Feb 04 '14 at 02:56
  • There's no `best` way... – walther Feb 04 '14 at 02:57
  • He doesn't deserve a down vote though. – Ean V Feb 04 '14 at 03:15
  • @walther, are you asserting this as a general rule? Or just in this specific case? Either way, I believe there actually would be a "best" answer here given enough parameters. – Kirk Woll Feb 04 '14 at 03:15
  • @KirkWoll, when it comes to patterns and software architecture, you can barely talk about `the best ultimate solution`. It's up to the programmer to decide what suits him and the specific situation the best and this isn't really a place to judge this for OP. All we can do is to suggest multiple options, but I somewhat doubt this kind of answer fits here...It's way too broad topic to enumerate various approaches, their pros and cons, etc. Yes, you can say the first example he's shown is bad and explain why, but you can't say about the second one that it's the best one... – walther Feb 04 '14 at 11:44
  • @walther, I am mystified why you are talking in such generalities. For this question one option likely leaks memory. If given two options and one is bad, choosing the other is hardly a matter of much opinion. I suspect this is just a kneejerk reaction of yours to his use of the word "best", which isn't terribly helpful. – Kirk Woll Feb 04 '14 at 14:18
  • @walther, it's obvious you are doing your best to figure out a way to interpret the question that leads to the least amount of help to the OP. I try to take a different tack. – Kirk Woll Feb 04 '14 at 17:15
  • Thos question belongs on another site in the Stack Exchange network, in particular CodeReview. – jmoreno Feb 12 '14 at 07:04

2 Answers2

3

There is one major difference here: The first code sample keeps a single DataContext for the lifetime of the service, while the second example spins up a new one for each operation. The second example is usually correct because with Change Tracking, DataContext can get huge and you can accidentially commit stuff you didn't mean to commit if something else calls SubmitChanges().

See Multiple/single instance of Linq to SQL DataContext

Community
  • 1
  • 1
Michael Stum
  • 177,530
  • 117
  • 400
  • 535
  • 1
    Good answer for an ambigious question. It's an important point to stress that retaining a data context for a long time is almost always a very bad idea. – Kirk Woll Feb 04 '14 at 03:14
0

You can use both patterns, but always make sure that the context will have a short lifespan. The first option allows you to create methods in CommonService that need a context, but without having to create one in each and every method. So it prevents repetitive code. Also, it allows IoC containers to inject a context into CommonService by constructor injection.

If you go for the first option (which I'd lean to doing), you may consider making CommonService implement IDisposable, giving it aDispose method in which the context is disposed. This will also encourage you to use the CommonService in a using construct and thus limit its lifespan.

Gert Arnold
  • 105,341
  • 31
  • 202
  • 291