В целом, можно.
Можно сделать сервис-локатор уровня приложения, посредством которого все модули могут получать те или иные сервисы.
А дальше, просто: Регистрируете сервис, который отдает нужную логику или просто Unit Of Work по верх DbContext-а и используете из плагина.
ApplicationBoostrap:
private void ConfigureContainerBuilder(ContainerBuilder builder)
{
builder.Register(c => EngineConfigurationHandler.Current)
.As<IConfiguration>().SingleInstance();
//Зарегистрируем сервисы
builder.RegisterAssemblyModules(typeof(RegisterDomainIocModule).Assembly);
builder.RegisterAssemblyModules(typeof(BaseService<>).Assembly);
builder.RegisterAssemblyModules(typeof(Bootstrapper).Assembly);
}
И, где-то в недрах:
using(var uov = ApplicationContext.Resolve<IUnitOfWork>())
{
var data = uov.Query<SomeDomainModel>().Where(...);
uow.Save(new SomeDomainModel{ Name = "Name" });
uow.Commit();
}
Почему я сказал про Unit Of Work,а не конкретный DbContext - потому что DbContext вы не контролируете, в отличии от вашего же Unit Of Work. И, соответственно, поддержку будет сделать куда проще. Опять же, в Unit Of Work вы можете напихать дополнительную логику пост- и пре-обработки (фильтрация по флагу IsDeleted), автоматическое присвоение ModifyDate при сохранение и т.п.
P.S. и да, я надеюсь, вы не имели ввиду Portable Library, вот тогда вам точно не обойтись от своих абстракций, определенных именно в Portable Library и повсеместно эксплуатируемых.
