mirror of https://github.com/abpframework/abp.git
634 changed files with 6816 additions and 4295 deletions
@ -1,11 +1,64 @@ |
|||||
# Data Access |
# Connection Strings |
||||
|
|
||||
ABP framework was designed as database agnostic, it can work any type of data source by the help of the [repository](Repositories.md) and [unit of work](Unit-Of-Work.md) abstractions. |
ABP Framework is designed to be [modular](Module-Development-Basics.md), [microservice compatible](Microservice-Architecture.md) and [multi-tenancy](Multi-Tenancy.md) aware. Connection string management is also designed to support these scenarios; |
||||
|
|
||||
However, currently the following providers are implements: |
* Allows to set separate connection strings for every module, so every module can have its own physical database. Modules even might be configured to use different DBMSs. |
||||
|
* Allows to set separate connection string and use a separate database per tenant (in a SaaS application). |
||||
|
|
||||
* [Entity Framework Core](Entity-Framework-Core.md) (works with [various DBMS and providers](https://docs.microsoft.com/en-us/ef/core/providers/?tabs=dotnet-core-cli).) |
It also supports hybrid scenarios; |
||||
* [MongoDB](MongoDB.md) |
|
||||
* [Dapper](Dapper.md) |
|
||||
|
|
||||
More providers might be added in the next releases. |
* Allows to group modules into databases (all modules into a single shared database, 2 modules to database A, 3 modules to database B, 1 module to database C and rest of the modules to database D... etc.) |
||||
|
* Allows to group tenants into databases, just like the modules. |
||||
|
* Allows to separate databases per tenant per module (which might be harder to maintain for you because of too many databases, but the ABP framework supports it). |
||||
|
|
||||
|
All the [pre-built application modules](Modules/Index.md) are designed to be compatible these scenarios. |
||||
|
|
||||
|
## Configure the Connection Strings |
||||
|
|
||||
|
See the following configuration: |
||||
|
|
||||
|
````json |
||||
|
"ConnectionStrings": { |
||||
|
"Default": "Server=localhost;Database=MyMainDb;Trusted_Connection=True;", |
||||
|
"AbpIdentityServer": "Server=localhost;Database=MyIdsDb;Trusted_Connection=True;", |
||||
|
"AbpPermissionManagement": "Server=localhost;Database=MyPermissionDb;Trusted_Connection=True;" |
||||
|
} |
||||
|
```` |
||||
|
|
||||
|
> ABP uses the `IConfiguration` service to get the application configuration. While the simplest way to write configuration into the `appsettings.json` file, it is not limited to this file. You can use environment variables, user secrets, Azure Key Vault... etc. See the [configuration](Configuration.md) document for more. |
||||
|
|
||||
|
This configuration defines three different connection strings: |
||||
|
|
||||
|
* `MyMainDb` (the `Default` connection string) is the main connection string of the application. If you don't specify a connection string for a module, it fallbacks to the `Default` connection string. The [application startup template](Startup-Templates/Application.md) is configured to use a single connection string, so all the modules uses a single shared database. |
||||
|
* `MyIdsDb` is used by the [IdentityServer](Modules/IdentityServer.md) module. |
||||
|
* `MyPermissionDb` is used by the [Permission Management](Modules/Permission-Management.md) module. |
||||
|
|
||||
|
[Pre-built application modules](Modules/Index.md) define constants for the connection string names. For example, the IdentityServer module defines a ` ConnectionStringName ` constant in the ` AbpIdentityServerDbProperties ` class (located in the ` Volo.Abp.IdentityServer ` namespace). Other modules similarly define constants, so you can investigate the connection string name. |
||||
|
|
||||
|
## Set the Connection String Name |
||||
|
|
||||
|
A module typically has a unique connection string name associated to its `DbContext` class using the `ConnectionStringName` attribute. Example: |
||||
|
|
||||
|
````csharp |
||||
|
[ConnectionStringName("AbpIdentityServer")] |
||||
|
public class IdentityServerDbContext |
||||
|
: AbpDbContext<IdentityServerDbContext>, IIdentityServerDbContext |
||||
|
{ |
||||
|
} |
||||
|
```` |
||||
|
|
||||
|
For [Entity Framework Core](Entity-Framework-Core.md) and [MongoDB](MongoDB.md), write this to your `DbContext` class (and the interface if it has). |
||||
|
|
||||
|
> If you are developing a reusable, database provider independent module see also [the best practices guide](Best-Practices/Index.md). |
||||
|
|
||||
|
## Database Migrations for the Entity Framework Core |
||||
|
|
||||
|
Relational databases require to create the database and the database schema (tables, views... etc.) before using it. |
||||
|
|
||||
|
The startup template (with EF Core ORM) comes with a single database and a `.EntityFrameworkCore.DbMigrations` project that contains the migration files for that database. This project mainly defines a *YourProjectName*MigrationsDbContext that calls the `Configure...()` methods of the used modules, like `builder.ConfigurePermissionManagement()`. |
||||
|
|
||||
|
Once you want to separate a module's database, you typically will need to create a second migration path. The easiest way to create a copy of the `.EntityFrameworkCore.DbMigrations` project with the `DbContext` inside it, change its content to only call the `Configure...()` methods of the modules needs to be stored in the second database and re-create the initial migration. In this case, you also need to change the `.DbMigrator` application to be able to work with these second database too. In this way, you will have a separate migrations DbContext per database. |
||||
|
|
||||
|
## Multi-Tenancy |
||||
|
|
||||
|
See [the multi-tenancy document](Multi-Tenancy.md) to learn how to use separate databases for tenants. |
||||
@ -1,11 +1,15 @@ |
|||||
# Data Access |
# Data Access |
||||
|
|
||||
ABP framework was designed as database agnostic, it can work any type of data source by the help of the [repository](Repositories.md) and [unit of work](Unit-Of-Work.md) abstractions. |
## Database Providers |
||||
|
|
||||
However, currently the following providers are implements: |
ABP framework was designed as database agnostic. It can work any type of data source by the help of the [repository](Repositories.md) and [unit of work](Unit-Of-Work.md) abstractions. However, currently the following providers are implemented: |
||||
|
|
||||
* [Entity Framework Core](Entity-Framework-Core.md) (works with [various DBMS and providers](https://docs.microsoft.com/en-us/ef/core/providers/?tabs=dotnet-core-cli).) |
* [Entity Framework Core](Entity-Framework-Core.md) (works with [various DBMS and providers](https://docs.microsoft.com/en-us/ef/core/providers/).) |
||||
* [MongoDB](MongoDB.md) |
* [MongoDB](MongoDB.md) |
||||
* [Dapper](Dapper.md) |
* [Dapper](Dapper.md) |
||||
|
|
||||
More providers might be added in the next releases. |
More providers will be added in the future. |
||||
|
|
||||
|
## See Also |
||||
|
|
||||
|
* [Connection Strings](Connection-Strings.md) |
||||
@ -0,0 +1,58 @@ |
|||||
|
# Switch to EF Core MySQL Provider |
||||
|
|
||||
|
This document explains how to switch to the **MySQL** database provider for **[the application startup template](Startup-Templates/Application.md)** which comes with SQL Server provider pre-configured. |
||||
|
|
||||
|
## Replace the Volo.Abp.EntityFrameworkCore.SqlServer Package |
||||
|
|
||||
|
`.EntityFrameworkCore` project in the solution depends on the [Volo.Abp.EntityFrameworkCore.SqlServer](https://www.nuget.org/packages/Volo.Abp.EntityFrameworkCore.SqlServer) NuGet package. Remove this package and add the same version of the [Volo.Abp.EntityFrameworkCore.MySQL](https://www.nuget.org/packages/Volo.Abp.EntityFrameworkCore.MySQL) package. |
||||
|
|
||||
|
## Replace the Module Dependency |
||||
|
|
||||
|
Find ***YourProjectName*EntityFrameworkCoreModule** class inside the `.EntityFrameworkCore` project, remove `typeof(AbpEntityFrameworkCoreSqlServerModule)` from the `DependsOn` attribute, add `typeof(AbpEntityFrameworkCoreMySQLModule)` (also replace `using Volo.Abp.EntityFrameworkCore.SqlServer;` with `using Volo.Abp.EntityFrameworkCore.MySQL;`). |
||||
|
|
||||
|
## UseMySQL() |
||||
|
|
||||
|
Find `UseSqlServer()` calls in your solution, replace with `UseMySQL()`. Check the following files: |
||||
|
|
||||
|
* *YourProjectName*EntityFrameworkCoreModule.cs inside the `.EntityFrameworkCore` project. |
||||
|
* *YourProjectName*MigrationsDbContextFactory.cs inside the `.EntityFrameworkCore.DbMigrations` project. |
||||
|
|
||||
|
> Depending on your solution structure, you may find more code files need to be changed. |
||||
|
|
||||
|
## Change the Connection Strings |
||||
|
|
||||
|
MySQL connection strings are different than SQL Server connection strings. So, check all `appsettings.json` files in your solution and replace the connection strings inside them. See the [connectionstrings.com]( https://www.connectionstrings.com/mysql/ ) for details of MySQL connection string options. |
||||
|
|
||||
|
You typically will change the `appsettings.json` inside the `.DbMigrator` and `.Web` projects, but it depends on your solution structure. |
||||
|
|
||||
|
## Change the Migrations DbContext |
||||
|
|
||||
|
MySQL DBMS has some slight differences than the SQL Server. Some module database mapping configuration (especially the field lengths) causes problems with MySQL. For example, some of the the [IdentityServer module](Modules/IdentityServer.md) tables has such problems and it provides an option to configure the fields based on your DBMS. |
||||
|
|
||||
|
The startup template contains a *YourProjectName*MigrationsDbContext which is responsible to maintain and migrate the database schema. This DbContext basically calls extension methods of the depended modules to configure their database tables. |
||||
|
|
||||
|
Open the *YourProjectName*MigrationsDbContext and change the `builder.ConfigureIdentityServer();` line as shown below: |
||||
|
|
||||
|
````csharp |
||||
|
builder.ConfigureIdentityServer(options => |
||||
|
{ |
||||
|
options.DatabaseProvider = EfCoreDatabaseProvider.MySql; |
||||
|
}); |
||||
|
```` |
||||
|
|
||||
|
Then `ConfigureIdentityServer()` method will set the field lengths to not exceed the MySQL limits. Refer to related module documentation if you have any problem while creating or executing the database migrations. |
||||
|
|
||||
|
## Re-Generate the Migrations |
||||
|
|
||||
|
The startup template uses [Entity Framework Core's Code First Migrations](https://docs.microsoft.com/en-us/ef/core/managing-schemas/migrations/). EF Core Migrations depend on the selected DBMS provider. So, changing the DBMS provider will cause the migration fails. |
||||
|
|
||||
|
* Delete the Migrations folder under the `.EntityFrameworkCore.DbMigrations` project and re-build the solution. |
||||
|
* Run `Add-Migration "Initial"` on the Package Manager Console (select the `.DbMigrator` (or `.Web`) project as the startup project in the Solution Explorer and select the `.EntityFrameworkCore.DbMigrations` project as the default project in the Package Manager Console). |
||||
|
|
||||
|
This will create a database migration with all database objects (tables) configured. |
||||
|
|
||||
|
Run the `.DbMigrator` project to create the database and seed the initial data. |
||||
|
|
||||
|
## Run the Application |
||||
|
|
||||
|
It is ready. Just run the application and enjoy coding. |
||||
@ -0,0 +1,41 @@ |
|||||
|
# Switch to EF Core PostgreSQL Provider |
||||
|
|
||||
|
This document explains how to switch to the **PostgreSQL** database provider for **[the application startup template](Startup-Templates/Application.md)** which comes with SQL Server provider pre-configured. |
||||
|
|
||||
|
## Replace the Volo.Abp.EntityFrameworkCore.SqlServer Package |
||||
|
|
||||
|
`.EntityFrameworkCore` project in the solution depends on the [Volo.Abp.EntityFrameworkCore.SqlServer](https://www.nuget.org/packages/Volo.Abp.EntityFrameworkCore.SqlServer) NuGet package. Remove this package and add the same version of the [Volo.Abp.EntityFrameworkCore.PostgreSql](https://www.nuget.org/packages/Volo.Abp.EntityFrameworkCore.PostgreSql) package. |
||||
|
|
||||
|
## Replace the Module Dependency |
||||
|
|
||||
|
Find ***YourProjectName*EntityFrameworkCoreModule** class inside the `.EntityFrameworkCore` project, remove `typeof(AbpEntityFrameworkCoreSqlServerModule)` from the `DependsOn` attribute, add `typeof(AbpEntityFrameworkCorePostgreSqlModule)` (also replace `using Volo.Abp.EntityFrameworkCore.SqlServer;` with `using Volo.Abp.EntityFrameworkCore.PostgreSql;`). |
||||
|
|
||||
|
## UsePostgreSql() |
||||
|
|
||||
|
Find `UseSqlServer()` calls in your solution, replace with `UsePostgreSql()`. Check the following files: |
||||
|
|
||||
|
* *YourProjectName*EntityFrameworkCoreModule.cs inside the `.EntityFrameworkCore` project. |
||||
|
* *YourProjectName*MigrationsDbContextFactory.cs inside the `.EntityFrameworkCore.DbMigrations` project. |
||||
|
|
||||
|
> Depending on your solution structure, you may find more code files need to be changed. |
||||
|
|
||||
|
## Change the Connection Strings |
||||
|
|
||||
|
PostgreSql connection strings are different than SQL Server connection strings. So, check all `appsettings.json` files in your solution and replace the connection strings inside them. See the [connectionstrings.com]( https://www.connectionstrings.com/postgresql/ ) for details of PostgreSql connection string options. |
||||
|
|
||||
|
You typically will change the `appsettings.json` inside the `.DbMigrator` and `.Web` projects, but it depends on your solution structure. |
||||
|
|
||||
|
## Re-Generate the Migrations |
||||
|
|
||||
|
The startup template uses [Entity Framework Core's Code First Migrations](https://docs.microsoft.com/en-us/ef/core/managing-schemas/migrations/). EF Core Migrations depend on the selected DBMS provider. So, changing the DBMS provider will cause the migration fails. |
||||
|
|
||||
|
* Delete the Migrations folder under the `.EntityFrameworkCore.DbMigrations` project and re-build the solution. |
||||
|
* Run `Add-Migration "Initial"` on the Package Manager Console (select the `.DbMigrator` (or `.Web`) project as the startup project in the Solution Explorer and select the `.EntityFrameworkCore.DbMigrations` project as the default project in the Package Manager Console). |
||||
|
|
||||
|
This will create a database migration with all database objects (tables) configured. |
||||
|
|
||||
|
Run the `.DbMigrator` project to create the database and seed the initial data. |
||||
|
|
||||
|
## Run the Application |
||||
|
|
||||
|
It is ready. Just run the application and enjoy coding. |
||||
@ -0,0 +1,41 @@ |
|||||
|
# Switch to EF Core SQLite Provider |
||||
|
|
||||
|
This document explains how to switch to the **SQLite** database provider for **[the application startup template](Startup-Templates/Application.md)** which comes with SQL Server provider pre-configured. |
||||
|
|
||||
|
## Replace the Volo.Abp.EntityFrameworkCore.SqlServer Package |
||||
|
|
||||
|
`.EntityFrameworkCore` project in the solution depends on the [Volo.Abp.EntityFrameworkCore.SqlServer](https://www.nuget.org/packages/Volo.Abp.EntityFrameworkCore.SqlServer) NuGet package. Remove this package and add the same version of the [Volo.Abp.EntityFrameworkCore.Sqlite](https://www.nuget.org/packages/Volo.Abp.EntityFrameworkCore.Sqlite) package. |
||||
|
|
||||
|
## Replace the Module Dependency |
||||
|
|
||||
|
Find ***YourProjectName*EntityFrameworkCoreModule** class inside the `.EntityFrameworkCore` project, remove `typeof(AbpEntityFrameworkCoreSqlServerModule)` from the `DependsOn` attribute, add `typeof(AbpEntityFrameworkCoreSqliteModule)` (also replace `using Volo.Abp.EntityFrameworkCore.SqlServer;` with `using Volo.Abp.EntityFrameworkCore.Sqlite;`). |
||||
|
|
||||
|
## UseSqlite() |
||||
|
|
||||
|
Find `UseSqlServer()` calls in your solution, replace with `UseSqlite()`. Check the following files: |
||||
|
|
||||
|
* *YourProjectName*EntityFrameworkCoreModule.cs inside the `.EntityFrameworkCore` project. |
||||
|
* *YourProjectName*MigrationsDbContextFactory.cs inside the `.EntityFrameworkCore.DbMigrations` project. |
||||
|
|
||||
|
> Depending on your solution structure, you may find more code files need to be changed. |
||||
|
|
||||
|
## Change the Connection Strings |
||||
|
|
||||
|
SQLite connection strings are different than SQL Server connection strings. So, check all `appsettings.json` files in your solution and replace the connection strings inside them. See the [connectionstrings.com]( https://www.connectionstrings.com/sqlite/ ) for details of SQLite connection string options. |
||||
|
|
||||
|
You typically will change the `appsettings.json` inside the `.DbMigrator` and `.Web` projects, but it depends on your solution structure. |
||||
|
|
||||
|
## Re-Generate the Migrations |
||||
|
|
||||
|
The startup template uses [Entity Framework Core's Code First Migrations](https://docs.microsoft.com/en-us/ef/core/managing-schemas/migrations/). EF Core Migrations depend on the selected DBMS provider. So, changing the DBMS provider will cause the migration fails. |
||||
|
|
||||
|
* Delete the Migrations folder under the `.EntityFrameworkCore.DbMigrations` project and re-build the solution. |
||||
|
* Run `Add-Migration "Initial"` on the Package Manager Console (select the `.DbMigrator` (or `.Web`) project as the startup project in the Solution Explorer and select the `.EntityFrameworkCore.DbMigrations` project as the default project in the Package Manager Console). |
||||
|
|
||||
|
This will create a database migration with all database objects (tables) configured. |
||||
|
|
||||
|
Run the `.DbMigrator` project to create the database and seed the initial data. |
||||
|
|
||||
|
## Run the Application |
||||
|
|
||||
|
It is ready. Just run the application and enjoy coding. |
||||
@ -1,73 +0,0 @@ |
|||||
## Entity Framework Core PostgreSQL Integration |
|
||||
|
|
||||
> See [Entity Framework Core Integration document](../Entity-Framework-Core.md) for the basics of the EF Core integration. |
|
||||
|
|
||||
### EntityFrameworkCore Project Update |
|
||||
|
|
||||
- In `Acme.BookStore.EntityFrameworkCore` project replace package `Volo.Abp.EntityFrameworkCore.SqlServer` with `Volo.Abp.EntityFrameworkCore.PostgreSql` |
|
||||
- Update to use PostgreSQL in `BookStoreEntityFrameworkCoreModule` |
|
||||
- Replace the `AbpEntityFrameworkCoreSqlServerModule` with the `AbpEntityFrameworkCorePostgreSqlModule` |
|
||||
- Replace the `options.UseSqlServer()` with the `options.UsePostgreSql()` |
|
||||
- In other projects update the PostgreSQL connection string in necessary `appsettings.json` files |
|
||||
- more info of [PostgreSQL connection strings](https://www.connectionstrings.com/postgresql/),You need to pay attention to `Npgsql` in this document |
|
||||
|
|
||||
### EntityFrameworkCore.DbMigrations Project Update |
|
||||
- Update to use PostgreSQL in `XXXMigrationsDbContextFactory` |
|
||||
- Replace the `new DbContextOptionsBuilder<XXXMigrationsDbContext>().UseSqlServer()` with the `new DbContextOptionsBuilder<XXXMigrationsDbContext>().UseNpgsql()` |
|
||||
|
|
||||
### Delete Existing Migrations |
|
||||
|
|
||||
Delete all existing migration files (including `DbContextModelSnapshot`) |
|
||||
|
|
||||
 |
|
||||
|
|
||||
### Regenerate Initial Migration |
|
||||
|
|
||||
Set the correct startup project (usually a web project) |
|
||||
|
|
||||
 |
|
||||
|
|
||||
Open the **Package Manager Console** (Tools -> Nuget Package Manager -> Package Manager Console), select the `.EntityFrameworkCore.DbMigrations` as the **Default project** and execute the following command: |
|
||||
|
|
||||
Run `Add-Migration` command. |
|
||||
```` |
|
||||
PM> Add-Migration Initial |
|
||||
```` |
|
||||
|
|
||||
### Update the Database |
|
||||
|
|
||||
You have two options to create the database. |
|
||||
|
|
||||
#### Using the DbMigrator Application |
|
||||
|
|
||||
The solution contains a console application (named `Acme.BookStore.DbMigrator` in this sample) that can create database, apply migrations and seed initial data. It is useful on development as well as on production environment. |
|
||||
|
|
||||
> `.DbMigrator` project has its own `appsettings.json`. So, if you have changed the connection string above, you should also change this one. |
|
||||
|
|
||||
Right click to the `.DbMigrator` project and select **Set as StartUp Project**: |
|
||||
|
|
||||
 |
|
||||
|
|
||||
Hit F5 (or Ctrl+F5) to run the application. It will have an output like shown below: |
|
||||
|
|
||||
 |
|
||||
|
|
||||
#### Using EF Core Update-Database Command |
|
||||
|
|
||||
Ef Core has `Update-Database` command which creates database if necessary and applies pending migrations. |
|
||||
|
|
||||
Set the correct startup project (usually a web project) |
|
||||
|
|
||||
 |
|
||||
|
|
||||
Open the **Package Manager Console** (Tools -> Nuget Package Manager -> Package Manager Console), select the `.EntityFrameworkCore.DbMigrations` as the **Default project** and execute the following command: |
|
||||
|
|
||||
```` |
|
||||
PM> Update-Database |
|
||||
```` |
|
||||
|
|
||||
This will create a new database based on the configured connection string. |
|
||||
|
|
||||
 |
|
||||
|
|
||||
> Using the `.DbMigrator` tool is the suggested way, because it also seeds the initial data to be able to properly run the web application. |
|
||||
@ -0,0 +1,3 @@ |
|||||
|
# IdentityServer Module |
||||
|
|
||||
|
TODO |
||||
@ -0,0 +1,31 @@ |
|||||
|
using System.Net; |
||||
|
using System.Threading.Tasks; |
||||
|
using Microsoft.AspNetCore.Mvc.Abstractions; |
||||
|
using Microsoft.AspNetCore.Mvc.Filters; |
||||
|
using Volo.Abp.DependencyInjection; |
||||
|
|
||||
|
namespace Volo.Abp.AspNetCore.Mvc.Response |
||||
|
{ |
||||
|
public class AbpNoContentActionFilter : IAsyncActionFilter, ITransientDependency |
||||
|
{ |
||||
|
public async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next) |
||||
|
{ |
||||
|
if (!context.ActionDescriptor.IsControllerAction()) |
||||
|
{ |
||||
|
await next(); |
||||
|
return; |
||||
|
} |
||||
|
|
||||
|
await next(); |
||||
|
|
||||
|
if (context.HttpContext.Response.StatusCode == (int)HttpStatusCode.OK) |
||||
|
{ |
||||
|
var returnType = context.ActionDescriptor.GetReturnType(); |
||||
|
if (returnType == typeof(Task) || returnType == typeof(void)) |
||||
|
{ |
||||
|
context.HttpContext.Response.StatusCode = (int)HttpStatusCode.NoContent; |
||||
|
} |
||||
|
} |
||||
|
} |
||||
|
} |
||||
|
} |
||||
@ -1,7 +1,9 @@ |
|||||
namespace Volo.Abp.BackgroundJobs |
using System.Threading.Tasks; |
||||
|
|
||||
|
namespace Volo.Abp.BackgroundJobs |
||||
{ |
{ |
||||
public interface IBackgroundJobExecuter |
public interface IBackgroundJobExecuter |
||||
{ |
{ |
||||
void Execute(JobExecutionContext context); |
Task ExecuteAsync(JobExecutionContext context); |
||||
} |
} |
||||
} |
} |
||||
@ -0,0 +1,55 @@ |
|||||
|
using System; |
||||
|
using System.Threading; |
||||
|
using System.Threading.Tasks; |
||||
|
using Microsoft.Extensions.DependencyInjection; |
||||
|
using Microsoft.Extensions.Logging; |
||||
|
using Volo.Abp.Threading; |
||||
|
|
||||
|
namespace Volo.Abp.BackgroundWorkers |
||||
|
{ |
||||
|
public abstract class AsyncPeriodicBackgroundWorkerBase : BackgroundWorkerBase |
||||
|
{ |
||||
|
protected IServiceScopeFactory ServiceScopeFactory { get; } |
||||
|
protected AbpTimer Timer { get; } |
||||
|
|
||||
|
protected AsyncPeriodicBackgroundWorkerBase( |
||||
|
AbpTimer timer, |
||||
|
IServiceScopeFactory serviceScopeFactory) |
||||
|
{ |
||||
|
ServiceScopeFactory = serviceScopeFactory; |
||||
|
Timer = timer; |
||||
|
Timer.Elapsed += Timer_Elapsed; |
||||
|
} |
||||
|
|
||||
|
public override async Task StartAsync(CancellationToken cancellationToken = default) |
||||
|
{ |
||||
|
await base.StartAsync(cancellationToken).ConfigureAwait(false); |
||||
|
Timer.Start(cancellationToken); |
||||
|
} |
||||
|
|
||||
|
public override async Task StopAsync(CancellationToken cancellationToken = default) |
||||
|
{ |
||||
|
Timer.Stop(cancellationToken); |
||||
|
await base.StopAsync(cancellationToken).ConfigureAwait(false); |
||||
|
} |
||||
|
|
||||
|
private void Timer_Elapsed(object sender, System.EventArgs e) |
||||
|
{ |
||||
|
try |
||||
|
{ |
||||
|
using (var scope = ServiceScopeFactory.CreateScope()) |
||||
|
{ |
||||
|
AsyncHelper.RunSync( |
||||
|
() => DoWorkAsync(new PeriodicBackgroundWorkerContext(scope.ServiceProvider)) |
||||
|
); |
||||
|
} |
||||
|
} |
||||
|
catch (Exception ex) |
||||
|
{ |
||||
|
Logger.LogException(ex); |
||||
|
} |
||||
|
} |
||||
|
|
||||
|
protected abstract Task DoWorkAsync(PeriodicBackgroundWorkerContext workerContext); |
||||
|
} |
||||
|
} |
||||
@ -0,0 +1,14 @@ |
|||||
|
using System; |
||||
|
|
||||
|
namespace Volo.Abp.BackgroundWorkers |
||||
|
{ |
||||
|
public class PeriodicBackgroundWorkerContext |
||||
|
{ |
||||
|
public IServiceProvider ServiceProvider { get; } |
||||
|
|
||||
|
public PeriodicBackgroundWorkerContext(IServiceProvider serviceProvider) |
||||
|
{ |
||||
|
ServiceProvider = serviceProvider; |
||||
|
} |
||||
|
} |
||||
|
} |
||||
Some files were not shown because too many files changed in this diff
Loading…
Reference in new issue