I like for Repository to receive DbContext, and to very generically do the repository ations on their types, i.e. Get<T>, Single<T>, AddOrUpdate<T>, Delete<T> or whatever, some or all of which predicated. The trick is to then conjure up an appropriate DbSet<T> at the moment it is required, I keep mine in an IDictionary<Type, IListSource> collection for example, and only generate them as I need them. In EF parlance, I don't know how kosher that is, per se; the trick is, I think, to negotiate an apporpriate navigation bridging the gap from domain instances to EF entities, that are subsequently marked for appropriate Add, Update, or Delete. Which is easy enough to facilitate from domain with things like:

interface IModel
{
    bool IsDeleted { get; set; }
}

interface IModel<TId> : IModel
{
    TId Id { get; set; }

    // As a function of Id, usually.
    bool IsPersistent { get; }
}

Along these lines, at any rate. Then a given AddOrUpdate<T> may receive any such IModel and conduct the appropriate set of navigations.

Of course the trick is to inject the domain specific navigation, perhaps as a callback to the IRepository, such that it can do so in a truly and properly inversion of controlled manner, and keep repository very, very generic and reusable.

Then there is the matter of operating whether in a disconnected environment. Mine generally is, I get the set of data, and discard the repository, keep my database clean from connections. So then I must re-attach instances during that negotiation process, navigating to do the correct updates.

Other thoughts, nuggets, pearls?