M
M
Max Maximov2017-07-17 07:34:20
ASP.NET
Max Maximov, 2017-07-17 07:34:20

How to implement reading and executing requests from DBContext in a portable library?

Task: There is a system that does work. This system has its own plugins (.dll); these libraries define the business logic of the task. The system itself scans the folder with plugins, loads .dlls on the fly, launches and processes.
Problem: since these libraries must return some kind of response, too much pasta code turned out in view of the large amount of data. It turns out that now we are making a selection from the database in the system, then we transfer it to dlls, and then we receive the answer and update the database.
Question: is it possible to make .dlls accept some kind of DBContext, and they already work with the database there? If yes, how to implement it?

Answer the question

In order to leave comments, you need to log in

1 answer(s)
A
Alexander Kuznetsov, 2017-07-17
@DarkRaven

In general, it is possible.
You can make an application-level service locator, through which all modules can receive certain services.
And then, it's simple: Register a service that sends the necessary logic or just Unit Of Work on top of DbContext and use it from the plugin.
Application Boostrap:

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);
        }

And, somewhere in the depths:
using(var uov = ApplicationContext.Resolve<IUnitOfWork>())
{
    var data = uov.Query<SomeDomainModel>().Where(...);

    uow.Save(new SomeDomainModel{  Name = "Name" });
    uow.Commit();
}

Why I said about Unit Of Work, and not a specific DbContext - because you do not control DbContext, unlike your own Unit Of Work. And, accordingly, support will be made much easier. Again, in Unit Of Work, you can cram additional post- and pre-processing logic (filtering by the IsDeleted flag), automatically assigning ModifyDate when saving, etc.
PS and yes, I hope you didn't mean the Portable Library, then you definitely can't do without your abstractions, defined specifically in the Portable Library and widely used.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question