What's the convention for extending Linq datacontext with set based helper operations specific to one collection of entities only

Question

I might be vaguing out here but I'm looking for a nice place to put set based helper operations in linq so I can do things like;

db.Selections.ClearTemporary()

which does something like

db.DeleteAllOnSubmit(db.Selections.Where(s => s.Temporary))

Since I can figure out how to extend Table<Selection> the best I can do is create a static method in partial class of Selection (similar to Ruby) but I have to pass in the datacontext like;

Selection.ClearTemporary(MyDataContext)

This kind of sucks because I have two conventions for doing set based operations and I have to pass the data context to the static class.

I've seen other people recommending piling helper methods into a partial of the datacontext like;

myDataContext.ClearTemporarySelections();

But I feel this makes the dc a dumping ground for in-cohesive operations.

Surely I'm missing something. I hope so. What's the convention?

leppie · Answer 1 · 2010-03-31T05:39:20.870

2

public static class LinqExtensions
{
  public static void Clear<T>(this Table<T> t, Expression<Func<T,bool>> pred)
  {
    t.DeleteAllOnSubmit(t.Where(pred));
  }
}

Usage:

db.Selections.Clear(x => x.Temporary);

If needed, the DataContext can be accessed from a Table<T>.

edited Mar 31 '10 at 05:39

answered Mar 30 '10 at 08:53

leppie

115,091
17
196
297

Gives me something else to work with but applies to all entities. Since .Selections is actually getter for a generic type Table and not a class I suppose extending these are a dead end. Sorry to reply so late I never received notification by email of this. – Luke Rohde Mar 30 '10 at 22:30
Adding `SubmitChanges` is a terrible idea here (extremely unintuitive with unpredictable side effects). I'll turn my -1 to a +1 without it. – Sam Harwell Mar 30 '10 at 22:58
I just realized you answered by question title perfectly - great answer stupid question. I've edited my question title but what's the protocol? – Luke Rohde Mar 30 '10 at 22:59
Yeah I was sketchy about the submit changes as it could unleash all sorts of mayhem on the unsuspecting user. However I was pretty pleased to discover Table has a context reference to the parent context - I'd been looking for that in other scenarios. – Luke Rohde Mar 30 '10 at 23:01
@280Z28: I know it is terrible :) It was an example of how to get to the DataContext from a Table so only one parameter needs to be passed. – leppie Mar 31 '10 at 03:54
But you don't need the data context if you aren't submitting it. – Sam Harwell Mar 31 '10 at 05:19
@280Z28: Ok, I'll remove it... but Luke did say he had the 'burden' of passing the datacontext. I am simply showing you do not need a datacontext when you have the table already :) – leppie Mar 31 '10 at 05:38

score 0 · Answer 2 · answered Mar 30 '10 at 22:48

I'm thinking of creating nested classes as partials of the datacontext plus a getter that initializes and returns the nested class

public SelectionsHelperClass SelectionsHelper {
  get {
    return new SelectionsHelperClass(Selections)
  }
}

This way I can do db.SelectionsHelper.ClearTemporary() without passing in the context while keeping set based operations (collection operations) specific to Selections logically together. I haven't tested this.

Something I forgot to mentioned is that reason I want these helpers is that they are frequently shared by some but not all controllers in an asp mvc app and I'm looking for a place to refactor them too.

I've tested this and it works ok. My first usage was for a lookup table - So now I can do things like db.LookupsHelper.GetDropDownValues("User.Type"); instead of - from l in db.lookups where attribute == "User.Type" select new {l.lookupid, l.displaytext} — Luke Rohde, Mar 31 '10 at 09:14

What's the convention for extending Linq datacontext with set based helper operations specific to one collection of entities only

2 Answers2