mirror of https://github.com/abpframework/abp.git
Halil İbrahim Kalkan
4 years ago
166 changed files with 7695 additions and 4173 deletions
@ -0,0 +1,99 @@ |
|||
# Deploying to a Clustered Environment |
|||
|
|||
This document introduces the topics that you should consider when you are deploying your application to a clustered environment where **multiple instances of your application run concurrently**, and explains how you can deal with these topics in your ABP based application. |
|||
|
|||
> This document is valid regardless you have a monolith application or a microservice solution. The Application term is used for a process. An application can be a monolith web application, a service in a microservice solution, a console application, or another kind of an executable process. |
|||
> |
|||
> For example, if you are deploying your application to Kubernetes and configure your application or service to run in multiple pods, then your application or service runs in a clustered environment. |
|||
|
|||
## Understanding the Clustered Environment |
|||
|
|||
> You can skip this section if you are already familiar with clustered deployment and load balancers. |
|||
|
|||
### Single Instance Deployment |
|||
|
|||
Consider an application deployed as a **single instance**, as illustrated in the following figure: |
|||
|
|||
 |
|||
|
|||
Browsers and other client applications can directly make HTTP requests to your application. You can put a web server (e.g. IIS or NGINX) between the clients and your application, but you still have a single application instance running in a single server or container. Single-instance configuration is **limited to scale** since it runs in a single server and you are limited with the server's capacity. |
|||
|
|||
### Clustered Deployment |
|||
|
|||
**Clustered deployment** is the way of running **multiple instances** of your application **concurrently** in a single or multiple servers. In this way, different instances can serve different requests and you can scale by adding new servers to the system. The following figure shows a typical implementation of clustering using a **load balancer**: |
|||
|
|||
 |
|||
|
|||
### Load Balancers |
|||
|
|||
[Load balancers](https://en.wikipedia.org/wiki/Load_balancing_(computing)) have a lot of features, but they fundamentally **forward an incoming HTTP request** to an instance of your application and return your response back to the client application. |
|||
|
|||
Load balancers can use different algorithms for selecting the application instance while determining the application instance that is used to deliver the incoming request. **Round Robin** is one of the simplest and most used algorithms. Requests are delivered to the application instances in rotation. First instance gets the first request, second instance gets the second, and so on. It returns to the first instance after all the instances are used, and the algorithm goes like that for the next requests. |
|||
|
|||
### Potential Problems |
|||
|
|||
Once multiple instances of your application run in parallel, you should carefully consider the following topics: |
|||
|
|||
* Any **state (data) stored in memory** of your application will become a problem when you have multiple instances. A state stored in memory of an application instance may not be available in the next request since the next request will be handled by a different application instance. While there are some solutions (like sticky sessions) to overcome this problem user-basis, it is a **best practice to design your application as stateless** if you want to run it in a cluster, container or/and cloud. |
|||
* **In-memory caching** is a kind of in-memory state and should not be used in a clustered application. You should use **distributed caching** instead. |
|||
* You shouldn't store data in the **local file system**. It should be available to all instances of your application. Different application instance may run in different containers or servers and they may not be able to have access to the same file system. You can use a **cloud or external storage provider** as a solution. |
|||
* If you have **background workers** or **job queue managers**, you should be careful since multiple instances may try to execute the same job or perform the same work concurrently. As a result, you may have the same work done multiple times or you may get a lot of errors while trying to access and change the same resources. |
|||
|
|||
You may have more problems with clustered deployment, but these are the most common ones. ABP has been designed to be compatible with the clustered deployment scenario. The following sections explain what you should do when you are deploying your ABP based application to a clustered environment. |
|||
|
|||
## Switching to a Distributed Cache |
|||
|
|||
ASP.NET Core provides different kind of caching features. [In-memory cache](https://docs.microsoft.com/en-us/aspnet/core/performance/caching/memory) stores your objects in the memory of the local server and is only available to the application that stored the object. Non-sticky sessions in a clustered environment should use the [distributed caching](https://docs.microsoft.com/en-us/aspnet/core/performance/caching/distributed) except some specific scenarios (for example, you can cache a local CSS file into memory. It is read-only data and it is the same in all application instances. You can cache it in memory for performance reasons without any problem). |
|||
|
|||
[ABP's Distributed Cache](../Caching.md) extends [ASP.NET Core's distributed cache](https://docs.microsoft.com/en-us/aspnet/core/performance/caching/distributed) infrastructure. It works in-memory by default. You should configure an actual distributed cache provider when you want to deploy your application to a clustered environment. |
|||
|
|||
> You should configure the cache provider for clustered deployment, even if your application doesn't directly use `IDistributedCache`. Because the ABP Framework and the pre-built [application modules](../Modules/Index.md) are using distributed cache. |
|||
|
|||
ASP.NET Core provides multiple integrations to use as your distributed cache provider, like [Redis](https://redis.io/) and [NCache](https://www.alachisoft.com/ncache/). You can follow [Microsoft's documentation](https://docs.microsoft.com/en-us/aspnet/core/performance/caching/distributed) to learn how to use them in your applications. |
|||
|
|||
If you decided to use Redis as your distributed cache provider, **follow [ABP's Redis Cache Integration document](../Redis-Cache.md)** for the steps you need to follow to install it into your application and setup your Redis configuration. |
|||
|
|||
> Based on your preferences while creating a new ABP solution, Redis cache might be pre-installed in your solution. For example, if you have selected the *Tiered* option with the MVC UI, Redis cache comes as pre-installed. Because, in this case, you have two applications in your solution and they should use the same cache source to be consistent. |
|||
|
|||
## Using a Proper BLOB Storage Provider |
|||
|
|||
If you have used ABP's [BLOB Storing](../Blob-Storing.md) feature with the [File System provider](../Blob-Storing-File-System.md), you should use another provider in your clustered environment since the File System provider uses the application's local file system. |
|||
|
|||
The [Database BLOB provider](../Blob-Storing-Database) is the easiest way since it uses your application's main database (or another database if you configure) to store BLOBs. However, you should remember that BLOBs are large objects and may quickly increase your database's size. |
|||
|
|||
> [ABP Commercial](https://commercial.abp.io/) startup solution templates come with the database BLOB provider as pre-installed, and stores BLOBs in the application's database. |
|||
|
|||
Check the [BLOB Storing](../Blob-Storing.md) document to see all the available BLOG storage providers. |
|||
|
|||
## Configuring Background Jobs |
|||
|
|||
ABP's [background job system](../Background-Jobs.md) is used to queue tasks to be executed in the background. Background job queue is persistent and a queued task is guaranteed to be executed (it is re-tried if it fails). |
|||
|
|||
ABP's default background job manager is compatible with clustered environments. It uses a [distributed lock](../Distributed-Locking.md) to ensure that the jobs are executed only in a single application instance at a time. See the *Configuring a Distributed Lock Provider* section below to learn how to configure a distributed lock provider for your application, so the default background job manager properly works in a clustered environment. |
|||
|
|||
If you don't want to use a distributed lock provider, you may go with the following options: |
|||
|
|||
* Stop the background job manager (set `AbpBackgroundJobOptions.IsJobExecutionEnabled` to `false`) in all application instances except one of them, so only the single instance executes the jobs (while other application instances can still queue jobs). |
|||
* Stop the background job manager (set `AbpBackgroundJobOptions.IsJobExecutionEnabled` to `false`) in all application instances and create a dedicated application (maybe a console application running in its own container or a Windows Service running in the background) to execute all the background jobs. This can be a good option if your background jobs consume high system resources (CPU, RAM or Disk), so you can deploy that background application to a dedicated server and your background jobs don't affect your application's performance. |
|||
|
|||
> If you are using an external background job integration (e.g. [Hangfire](../Background-Workers-Hangfire.md) or [Quartz](../Background-Workers-Quartz.md)) instead of the default background job manager, then please refer to your provider's documentation to learn how it should be configured for a clustered environment. |
|||
|
|||
## Configuring a Distributed Lock Provider |
|||
|
|||
ABP provides a distributed locking abstraction with an implementation made with the [DistributedLock](https://github.com/madelson/DistributedLock) library. A distributed lock is used to control concurrent access to a shared resource by multiple applications to prevent corruption of the resource because of concurrent writes. The ABP Framework and some pre-built [application modules](../Modules/Index.md) are using distributed locking for several reasons. |
|||
|
|||
However, the distributed lock system works in-process by default. That means it is not distributed actually, unless you configure a distributed lock provider. So, please follow the [distributed lock](../Distributed-Locking.md) document to configure a provider for your application, if it is not already configured. |
|||
|
|||
## Implementing Background Workers |
|||
|
|||
ASP.NET Core provides [hosted services](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/host/hosted-services) and ABP provides [background workers](../Background-Workers.md) to perform tasks in background threads in your application. |
|||
|
|||
If your application has tasks running in the background, you should consider how they will behave in a clustered environment, especially if your background tasks are using the same resources. You should design your background tasks so that they continue to work properly in the clustered environment. |
|||
|
|||
Assume that your background worker in your SaaS application checks user subscriptions and sends emails if their subscription renewal date approaches. If the background task runs in multiple application instances, it is probable to send the same email many times to some users, which will disturb them. |
|||
|
|||
We suggest you to use one of the following approaches to overcome the problem: |
|||
|
|||
* Implement your background workers so that they work in a clustered environment without any problem. Using the [distributed lock](../Distributed-Locking.md) to ensure concurrency control is a way of doing that. A background worker in an application instance may handle a distributed lock, so the workers in other application instances will wait for the lock. In this way, only one worker does the actual work, while others wait in idle. If you implement this, your workers run safely without caring about how the application is deployed. |
|||
* Stop the background workers (set `AbpBackgroundWorkerOptions.IsEnabled` to `false`) in all application instances except one of them, so only the single instance runs the workers. |
|||
* Stop the background workers (set `AbpBackgroundWorkerOptions.IsEnabled` to `false`) in all application instances and create a dedicated application (maybe a console application running in its own container or a Windows Service running in the background) to execute all the background tasks. This can be a good option if your background workers consume high system resources (CPU, RAM or Disk), so you can deploy that background application to a dedicated server and your background tasks don't affect your application's performance. |
|||
@ -0,0 +1,9 @@ |
|||
# Deployment |
|||
|
|||
Deploying an ABP application is not different than deploying any .NET or ASP.NET Core application. You can deploy it to a cloud provider (e.g. Azure, AWS, Google Could) or on-premise server, IIS or any other web server. ABP's documentation doesn't contain much information on deployment. You can refer to your provider's documentation. |
|||
|
|||
However, there are some topics that you should care about when you are deploying your applications. Most of them are general software deployment considerations, but you should understand how to handle them within your ABP based applications. We've prepared guides for this purpose and we suggest you to read these guides carefully before designing your deployment configuration. |
|||
|
|||
## Guides |
|||
|
|||
* [Deploying to a clustered environment](Clustered-Environment.md): Explains how to configure your application when you want to run multiple instances of your application concurrently. |
|||
@ -0,0 +1,82 @@ |
|||
# LeptonX Lite Angular UI |
|||
LeptonX Lite has implementation for the ABP Framework Angular Client. It's a simplified variation of the [LeptonX Theme](https://x.leptontheme.com/). |
|||
|
|||
> If you are looking for a professional, enterprise ready theme, you can check the [LeptonX Theme](https://x.leptontheme.com/), which is a part of [ABP Commercial](https://commercial.abp.io/). |
|||
|
|||
> See the [Theming document](https://docs.abp.io/en/abp/latest/UI/AspNetCore/Theming) to learn about themes. |
|||
|
|||
## Installation |
|||
|
|||
To add `LeptonX-lite` into your project, |
|||
|
|||
* Install `@abp/ng.theme.lepton-x` |
|||
|
|||
`yarn add @abp/ng.theme.lepton-x@preview` |
|||
|
|||
* Install `bootstrap-icons` |
|||
|
|||
`yarn add bootstrap-icons` |
|||
|
|||
|
|||
* Then, we need to edit the styles array in `angular.json` to replace the existing style with the new one. |
|||
|
|||
Add the following style |
|||
|
|||
```json |
|||
"node_modules/bootstrap-icons/font/bootstrap-icons.css", |
|||
``` |
|||
|
|||
* Finally, remove `ThemeBasicModule` from `app.module.ts`, and import the related modules in `app.module.ts` |
|||
|
|||
```js |
|||
import { ThemeLeptonXModule } from '@abp/ng.theme.lepton-x'; |
|||
import { SideMenuLayoutModule } from '@abp/ng.theme.lepton-x/layouts'; |
|||
|
|||
@NgModule({ |
|||
imports: [ |
|||
// ... |
|||
|
|||
// do not forget to remove ThemeBasicModule |
|||
// ThemeBasicModule.forRoot(), |
|||
ThemeLeptonXModule.forRoot(), |
|||
SideMenuLayoutModule.forRoot(), |
|||
], |
|||
// ... |
|||
}) |
|||
export class AppModule {} |
|||
``` |
|||
|
|||
Note: If you employ [Resource Owner Password Flow](https://docs.abp.io/en/abp/latest/UI/Angular/Authorization#resource-owner-password-flow) for authorization, you should import the following module as well: |
|||
|
|||
```js |
|||
import { AccountLayoutModule } from '@abp/ng.theme.lepton-x/account'; |
|||
|
|||
@NgModule({ |
|||
// ... |
|||
imports: [ |
|||
// ... |
|||
AccountLayoutModule.forRoot(), |
|||
// ... |
|||
], |
|||
// ... |
|||
}) |
|||
export class AppModule {} |
|||
``` |
|||
|
|||
To change the logos and brand color of `LeptonX`, simply add the following CSS to the `styles.scss` |
|||
|
|||
```css |
|||
:root { |
|||
--lpx-logo: url('/assets/images/logo.png'); |
|||
--lpx-logo-icon: url('/assets/images/logo-icon.png'); |
|||
--lpx-brand: #edae53; |
|||
} |
|||
``` |
|||
|
|||
- `--lpx-logo` is used to place the logo in the menu. |
|||
- `--lpx-logo-icon` is a square icon used when the menu is collapsed. |
|||
- `--lpx-brand` is a color used throughout the application, especially on active elements. |
|||
|
|||
### Server Side |
|||
|
|||
In order to migrate to LeptonX on your server side projects (Host and/or IdentityServer projects), please follow the [Server Side Migration](mvc.md) document. |
|||
@ -0,0 +1,130 @@ |
|||
# LeptonX Lite Blazor UI |
|||
|
|||
````json |
|||
//[doc-params] |
|||
{ |
|||
"UI": ["Blazor", "BlazorServer"] |
|||
} |
|||
```` |
|||
|
|||
LeptonX Lite has implementation for the ABP Framework Blazor WebAssembly & Blazor Server. It's a simplified variation of the [LeptonX Theme](https://x.leptontheme.com/). |
|||
|
|||
> If you are looking for a professional, enterprise ready theme, you can check the [LeptonX Theme](https://x.leptontheme.com/), which is a part of [ABP Commercial](https://commercial.abp.io/). |
|||
|
|||
> See the [Theming document](https://docs.abp.io/en/abp/latest/UI/AspNetCore/Theming) to learn about themes. |
|||
|
|||
## Installation |
|||
|
|||
{{if UI == "Blazor"}} |
|||
- Complete the [MVC Razor Pages Installation](mvc.md#installation) for the **HttpApi.Host** application first. _If the solution is tiered/micro-service, complete the MVC steps for all MVC applications such as **HttpApi.Host** and if identity server is separated, install to the **IdentityServer**_. |
|||
|
|||
- Add **Volo.Abp.AspNetCore.Components.WebAssembly.LeptonXLiteTheme** package to your **Blazor WebAssembly** application. |
|||
```bash |
|||
dotnet add package Volo.Abp.AspNetCore.Components.WebAssembly.LeptonXLiteTheme |
|||
``` |
|||
|
|||
- Remove the old theme from the **DependsOn** attribute in your module class and add the **AbpAspNetCoreComponentsWebAssemblyLeptonXLiteThemeModule** type to the **DependsOn** attribute. |
|||
|
|||
```diff |
|||
[DependsOn( |
|||
- typeof(AbpAspNetCoreComponentsWebAssemblyBasicThemeModule), |
|||
+ typeof(AbpAspNetCoreComponentsWebAssemblyLeptonXLiteThemeModule) |
|||
)] |
|||
``` |
|||
|
|||
- Change startup App component with the LeptonX one. |
|||
|
|||
```csharp |
|||
// Make sure the 'App' comes from 'Volo.Abp.AspNetCore.Components.Web.LeptonXLiteTheme.Themes.LeptonXLite' namespace. |
|||
builder.RootComponents.Add<App>("#ApplicationContainer"); |
|||
``` |
|||
|
|||
- Run the `abp bundle` command in your **Blazor** application folder. |
|||
|
|||
{{end}} |
|||
|
|||
|
|||
{{if UI == "BlazorServer"}} |
|||
|
|||
- Complete the [MVC Razor Pages Installation](mvc.md#installation) first. _If the solution is tiered/micro-service, complete the MVC steps for all MVC applications such as **HttpApi.Host** and **IdentityServer**_. |
|||
|
|||
- Add **Volo.Abp.AspNetCore.Components.Server.LeptonXLiteTheme** package to your **Blazor server** application. |
|||
```bash |
|||
dotnet add package Volo.Abp.AspNetCore.Components.Server.LeptonXLiteTheme |
|||
``` |
|||
|
|||
- Remove old theme from the **DependsOn** attribute in your module class and add the **AbpAspNetCoreComponentsWebAssemblyLeptonXLiteThemeModule** type to the **DependsOn** attribute. |
|||
|
|||
```diff |
|||
[DependsOn( |
|||
- typeof(AbpAspNetCoreComponentsServerBasicThemeModule), |
|||
+ typeof(AbpAspNetCoreComponentsServerLeptonXLiteThemeModule) |
|||
)] |
|||
``` |
|||
|
|||
- Update AbpBundlingOptions |
|||
```diff |
|||
options.StyleBundles.Configure( |
|||
- BlazorBasicThemeBundles.Styles.Global, |
|||
+ BlazorLeptonXLiteThemeBundles.Styles.Global, |
|||
bundle => |
|||
{ |
|||
bundle.AddFiles("/blazor-global-styles.css"); |
|||
//You can remove the following line if you don't use Blazor CSS isolation for components |
|||
bundle.AddFiles("/MyProjectName.Blazor.styles.css"); |
|||
}); |
|||
``` |
|||
|
|||
- Update `_Host.cshtml` file. _(located under **Pages** folder by default.)_ |
|||
|
|||
- Add following usings to Locate **App** and **BlazorLeptonXLiteThemeBundles** classes. |
|||
```csharp |
|||
@using Volo.Abp.AspNetCore.Components.Web.LeptonXLiteTheme.Themes.LeptonXLite |
|||
@using Volo.Abp.AspNetCore.Components.Server.LeptonXLiteTheme.Bundling |
|||
``` |
|||
- Then replace script & style bundles as following: |
|||
```diff |
|||
- <abp-style-bundle name="@BlazorBasicThemeBundles.Styles.Global" /> |
|||
+ <abp-style-bundle name="@BlazorLeptonXLiteThemeBundles.Styles.Global" /> |
|||
``` |
|||
|
|||
```diff |
|||
- <abp-script-bundle name="@BlazorBasicThemeBundles.Scripts.Global" /> |
|||
+ <abp-script-bundle name="@BlazorLeptonXLiteThemeBundles.Scripts.Global" /> |
|||
``` |
|||
|
|||
{{end}} |
|||
|
|||
|
|||
--- |
|||
|
|||
## Customization |
|||
|
|||
### Toolbars |
|||
LeptonX Lite includes separeted toolbars for desktop & mobile. You can manage toolbars independently. Toolbar names can be accessible in the **LeptonXLiteToolbars** class. |
|||
|
|||
- `LeptonXLiteToolbars.Main` |
|||
- `LeptonXLiteToolbars.MainMobile` |
|||
|
|||
```csharp |
|||
public async Task ConfigureToolbarAsync(IToolbarConfigurationContext context) |
|||
{ |
|||
if (context.Toolbar.Name == LeptonXLiteToolbars.Main) |
|||
{ |
|||
context.Toolbar.Items.Add(new ToolbarItem(typeof(MyDesktopComponent))); |
|||
} |
|||
|
|||
if (context.Toolbar.Name == LeptonXLiteToolbars.MainMobile) |
|||
{ |
|||
context.Toolbar.Items.Add(new ToolbarItem(typeof(MyMobileComponent))); |
|||
} |
|||
|
|||
return Task.CompletedTask; |
|||
} |
|||
``` |
|||
|
|||
{{if UI == "BlazorServer"}} |
|||
|
|||
> _You can visit the [Toolbars Documentation](https://docs.abp.io/en/abp/latest/UI/Blazor/Toolbars) for better understanding._ |
|||
|
|||
{{end}} |
|||
@ -0,0 +1,67 @@ |
|||
# LeptonX Lite MVC UI |
|||
LeptonX Lite has implementation for the ABP Framework Razor Pages. It's a simplified variation of the [LeptonX Theme](https://x.leptontheme.com/). |
|||
|
|||
> If you are looking for a professional, enterprise ready theme, you can check the [LeptonX Theme](https://x.leptontheme.com/), which is a part of [ABP Commercial](https://commercial.abp.io/). |
|||
|
|||
> See the [Theming document](https://docs.abp.io/en/abp/latest/UI/AspNetCore/Theming) to learn about themes. |
|||
|
|||
## Installation |
|||
|
|||
- Add **Volo.Abp.AspNetCore.Mvc.UI.Theme.LeptonXLite** package to your **Web** application. |
|||
|
|||
```bash |
|||
abp add-package Volo.Abp.AspNetCore.Mvc.UI.Theme.LeptonXLite |
|||
``` |
|||
|
|||
- Make sure the old theme is removed and LeptonX is added in your Module class. |
|||
|
|||
```diff |
|||
[DependsOn( |
|||
- typeof(AbpAspNetCoreMvcUiBasicThemeModule), |
|||
+ typeof(AbpAspNetCoreMvcUiLeptonXLiteThemeModule) |
|||
)] |
|||
``` |
|||
|
|||
- Update AbpBundlingOptions |
|||
|
|||
```diff |
|||
Configure<AbpBundlingOptions>(options => |
|||
{ |
|||
options.StyleBundles.Configure( |
|||
- BasicThemeBundles.Styles.Global, |
|||
+ LeptonXLiteThemeBundles.Styles.Global |
|||
bundle => |
|||
{ |
|||
bundle.AddFiles("/global-styles.css"); |
|||
} |
|||
); |
|||
}); |
|||
``` |
|||
|
|||
--- |
|||
|
|||
## Customization |
|||
|
|||
### Toolbars |
|||
LeptonX Lite includes separeted toolbars for desktop & mobile. You can manage toolbars independently. Toolbar names can be accessible in the **LeptonXLiteToolbars** class. |
|||
|
|||
- `LeptonXLiteToolbars.Main` |
|||
- `LeptonXLiteToolbars.MainMobile` |
|||
|
|||
```csharp |
|||
public class MyProjectNameMainToolbarContributor : IToolbarContributor |
|||
{ |
|||
public async Task ConfigureToolbarAsync(IToolbarConfigurationContext context) |
|||
{ |
|||
if (context.Toolbar.Name == LeptonXLiteToolbars.Main) |
|||
{ |
|||
context.Toolbar.Items.Add(new ToolbarItem(typeof(MyDesktopComponent))); |
|||
} |
|||
|
|||
if (context.Toolbar.Name == LeptonXLiteToolbars.MainMobile) |
|||
{ |
|||
context.Toolbar.Items.Add(new ToolbarItem(typeof(MyMobileComponent))); |
|||
} |
|||
} |
|||
} |
|||
``` |
|||
@ -0,0 +1,29 @@ |
|||
# DateTime Format Pipes |
|||
|
|||
You can format date by Date pipe of angular. |
|||
|
|||
Example |
|||
|
|||
```html |
|||
<span> {{today | date 'dd/mm/yy'}}</span> |
|||
``` |
|||
|
|||
ShortDate, ShortTime and ShortDateTime format data like angular's data pipe but easier. Also the pipes get format from config service by culture. |
|||
|
|||
# ShortDate Pipe |
|||
|
|||
```html |
|||
<span> {{today | shortDatePipe }}</span> |
|||
``` |
|||
|
|||
# ShortTime Pipe |
|||
|
|||
```html |
|||
<span> {{today | shortTimePipe }}</span> |
|||
``` |
|||
|
|||
# ShortDateTime Pipe |
|||
|
|||
```html |
|||
<span> {{today | shortDateTimePipe }}</span> |
|||
``` |
|||
@ -0,0 +1,128 @@ |
|||
# Bootstrap Modules |
|||
|
|||
ABP framework can be bootstrapped in various applications. like ASP NET Core or Console, WPF, etc. |
|||
|
|||
Modules can be started sync or async, Corresponds to various event methods in the module. We recommend using **async**, Especially if you want to make async calls in the module's methods. |
|||
|
|||
The `PreConfigureServices`, `ConfigureServices`, `PostConfigureServices`, `OnPreApplicationInitialization`, `OnApplicationInitialization`, `OnPostApplicationInitialization` methods of module have the Async version. |
|||
|
|||
> Async methods automatically call sync methods by default. |
|||
|
|||
If you use async methods in your module, please keep the same sync methods for compatibility. |
|||
|
|||
````csharp |
|||
public async override Task OnApplicationInitializationAsync(ApplicationInitializationContext context) |
|||
{ |
|||
await AsyncMethod(); |
|||
} |
|||
|
|||
public override void OnApplicationInitialization(ApplicationInitializationContext context) |
|||
{ |
|||
AsyncHelper.RunSync(() => OnApplicationInitializationAsync(context)); |
|||
} |
|||
```` |
|||
|
|||
## ASP NET Core |
|||
|
|||
Bootstrap ABP by using [WebApplication](https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.builder.webapplication?view=aspnetcore-6.0) |
|||
|
|||
````csharp |
|||
var builder = WebApplication.CreateBuilder(args); |
|||
builder.Host.AddAppSettingsSecretsJson() |
|||
.UseAutofac(); |
|||
|
|||
await builder.Services.AddApplicationAsync<MyProjectNameWebModule>(); |
|||
var app = builder.Build(); |
|||
|
|||
await app.InitializeApplicationAsync(); |
|||
await app.RunAsync(); |
|||
```` |
|||
|
|||
## Console |
|||
|
|||
Bootstrap ABP in Console App. |
|||
|
|||
````csharp |
|||
var abpApplication = await AbpApplicationFactory.CreateAsync<MyProjectNameModule>(options => |
|||
{ |
|||
options.UseAutofac(); |
|||
}); |
|||
|
|||
await _abpApplication.InitializeAsync(); |
|||
|
|||
var helloWorldService = _abpApplication.ServiceProvider.GetRequiredService<HelloWorldService>(); |
|||
|
|||
await helloWorldService.SayHelloAsync(); |
|||
```` |
|||
|
|||
Bootstrap ABP by using [HostedService](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/host/hosted-services?view=aspnetcore-6.0&tabs=visual-studio#ihostedservice-interface) |
|||
|
|||
````csharp |
|||
public class MyHostedService : IHostedService |
|||
{ |
|||
private IAbpApplicationWithInternalServiceProvider _abpApplication; |
|||
|
|||
private readonly IConfiguration _configuration; |
|||
private readonly IHostEnvironment _hostEnvironment; |
|||
|
|||
public MyHostedService(IConfiguration configuration, IHostEnvironment hostEnvironment) |
|||
{ |
|||
_configuration = configuration; |
|||
_hostEnvironment = hostEnvironment; |
|||
} |
|||
|
|||
public async Task StartAsync(CancellationToken cancellationToken) |
|||
{ |
|||
_abpApplication = await AbpApplicationFactory.CreateAsync<MyProjectNameModule>(options => |
|||
{ |
|||
options.Services.ReplaceConfiguration(_configuration); |
|||
options.Services.AddSingleton(_hostEnvironment); |
|||
|
|||
options.UseAutofac(); |
|||
options.Services.AddLogging(loggingBuilder => loggingBuilder.AddSerilog()); |
|||
}); |
|||
|
|||
await _abpApplication.InitializeAsync(); |
|||
|
|||
var helloWorldService = _abpApplication.ServiceProvider.GetRequiredService<HelloWorldService>(); |
|||
|
|||
await helloWorldService.SayHelloAsync(); |
|||
} |
|||
|
|||
public async Task StopAsync(CancellationToken cancellationToken) |
|||
{ |
|||
await _abpApplication.ShutdownAsync(); |
|||
} |
|||
} |
|||
```` |
|||
|
|||
## WPF |
|||
|
|||
Bootstrap ABP on [OnStartup](https://docs.microsoft.com/en-us/dotnet/api/system.windows.application.onstartup?view=windowsdesktop-6.0) method. |
|||
|
|||
````csharp |
|||
public partial class App : Application |
|||
{ |
|||
private IAbpApplicationWithInternalServiceProvider _abpApplication; |
|||
|
|||
protected async override void OnStartup(StartupEventArgs e) |
|||
{ |
|||
_abpApplication = await AbpApplicationFactory.CreateAsync<MyProjectNameModule>(options => |
|||
{ |
|||
options.UseAutofac(); |
|||
options.Services.AddLogging(loggingBuilder => loggingBuilder.AddSerilog(dispose: true)); |
|||
}); |
|||
|
|||
await _abpApplication.InitializeAsync(); |
|||
|
|||
_abpApplication.Services.GetRequiredService<MainWindow>()?.Show(); |
|||
} |
|||
|
|||
protected async override void OnExit(ExitEventArgs e) |
|||
{ |
|||
await _abpApplication.ShutdownAsync(); |
|||
} |
|||
} |
|||
|
|||
```` |
|||
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 10 KiB |
|
After Width: | Height: | Size: 106 KiB |
|
After Width: | Height: | Size: 40 KiB |
|
After Width: | Height: | Size: 30 KiB |
@ -0,0 +1,248 @@ |
|||
# ABP CLI - 新解决方案命令示例 |
|||
|
|||
`abp new`命令基于abp模板创建abp解决方案或其他组件. [ABP CLI](CLI.md)有一些参数可以用于创建新的ABP解决方案. 在本文档中, 我们将向你展示一些创建新的解决方案的命令示例. 所有的项目名称都是`Acme.BookStore`. 目前, 唯一可用的移动端项目是`React Native`移动端应用程序. 可用的数据库提供程序有`Entity Framework Core`和`MongoDB`. 所有命令都以`abp new`开头. |
|||
|
|||
## Angular |
|||
|
|||
以下命令用于创建Angular UI项目: |
|||
|
|||
* 在新文件夹中创建项目, **Entity Framework Core**, 非移动端应用程序: |
|||
|
|||
````bash |
|||
abp new Acme.BookStore -u angular --mobile none --database-provider ef -csf |
|||
```` |
|||
|
|||
* 在新文件夹中创建项目, **Entity Framework Core**, 默认应用程序模板, **拆分Identity Server**: |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -t app -u angular -m none --separate-identity-server --database-provider ef -csf |
|||
``` |
|||
|
|||
* 在新文件夹中创建项目, **Entity Framework Core**, **自定义连接字符串**: |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -u angular -csf --connection-string Server=localhost;Database=MyDatabase;Trusted_Connection=True |
|||
``` |
|||
|
|||
* 在`C:\MyProjects\Acme.BookStore`中创建解决方案, **MongoDB**, 默认应用程序模板, 包含移动端项目: |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -u angular --database-provider mongodb --output-folder C:\MyProjects\Acme.BookStore |
|||
``` |
|||
|
|||
* 在新文件夹中创建项目, **MongoDB**, 默认应用程序模板, 不创建移动端应用程序, **拆分Identity Server**: |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -t app -u angular -m none --separate-identity-server --database-provider mongodb -csf |
|||
``` |
|||
|
|||
## MVC |
|||
|
|||
以下命令用于创建MVC UI项目: |
|||
|
|||
* 在新文件夹中创建项目, **Entity Framework Core**, 不创建移动端应用程序: |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -t app -u mvc --mobile none --database-provider ef -csf |
|||
``` |
|||
|
|||
* 在新文件夹中创建项目, **Entity Framework Core**, **分层结构** (*Web和HTTP API层是分开的*), 不创建移动端应用程序: |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -u mvc --mobile none --tiered --database-provider ef -csf |
|||
``` |
|||
|
|||
* 在新文件夹中创建项目, **MongoDB**, 不创建移动端应用程序: |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -t app -u mvc --mobile none --database-provider mongodb -csf |
|||
``` |
|||
|
|||
* 在新文件夹中创建项目, **MongoDB**, **分层结构**: |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -u mvc --tiered --database-provider mongodb -csf |
|||
``` |
|||
|
|||
|
|||
## Blazor |
|||
|
|||
以下命令用于创建Blazor项目: |
|||
|
|||
* **Entity Framework Core**, 不创建移动端应用程序: |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -t app -u blazor --mobile none |
|||
``` |
|||
|
|||
* **Entity Framework Core**, **拆分Identity Server**, 包含移动端应用程序: |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -u blazor --separate-identity-server |
|||
``` |
|||
|
|||
* 在新文件夹中创建项目, **MongoDB**, 不创建移动端应用程序: |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -u blazor --database-provider mongodb --mobile none -csf |
|||
``` |
|||
|
|||
## Blazor Server |
|||
|
|||
以下命令用于创建Blazor项目: |
|||
|
|||
* **Entity Framework Core**, 不创建移动端应用程序: |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -t app -u blazor-server --mobile none |
|||
``` |
|||
|
|||
* **Entity Framework Core**, **拆分Identity Server**, **拆分API Host**, 包含移动端应用程序: |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -u blazor-server --tiered |
|||
``` |
|||
|
|||
* 在新文件夹中创建项目, **MongoDB**, 不创建移动端应用程序: |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -u blazor --database-provider mongodb --mobile none -csf |
|||
``` |
|||
|
|||
## 无UI |
|||
|
|||
在默认应用程序模板中, 始终有一个前端项目. 在这个选项中没有前端项目. 它有一个`HttpApi.Host`项目为你的HTTP WebAPI提供服务. 这个选项适合在你想创建一个WebAPI服务时使用. |
|||
|
|||
* 在新文件夹中创建项目, **Entity Framework Core**, 拆分Identity Server: |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -u none --separate-identity-server -csf |
|||
``` |
|||
* **MongoDB**, 不创建移动端应用程序: |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -u none --mobile none --database-provider mongodb |
|||
``` |
|||
|
|||
|
|||
|
|||
## 控制台应用程序 |
|||
|
|||
这是一个基于.NET控制台应用程序的模板, 集成了ABP模块架构. 要创建控制台应用程序, 请使用以下命令: |
|||
|
|||
* 项目由以下文件组成: `Acme.BookStore.csproj`, `appsettings.json`, `BookStoreHostedService.cs`, `BookStoreModule.cs`, `HelloWorldService.cs` 和 `Program.cs`. |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -t console -csf |
|||
``` |
|||
|
|||
## 模块 |
|||
|
|||
模块是主项目使用的可重用子应用程序. 如果你正在构建微服务解决方案, 使用ABP模块是最佳方案. 由于模块不是最终的应用程序, 每个模块都有前端UI项目和数据库提供程序. 模块模板带有MVC UI, 可以在没有最终解决方案的情况下进行开发. 但是, 如果要在最终解决方案下开发模块, 可以添加`--no-ui`参数来去除MVC UI项目. |
|||
|
|||
* 包含前端: `MVC`, `Angular`, `Blazor`. 包含数据库提供程序: `Entity Framework Core`, `MongoDB`. 包含MVC启动项目. |
|||
|
|||
```bash |
|||
abp new Acme.IssueManagement -t module |
|||
``` |
|||
* 与上面相同, 但不包括MVC启动项目. |
|||
|
|||
```bash |
|||
abp new Acme.IssueManagement -t module --no-ui |
|||
``` |
|||
|
|||
* 创建模块并将其添加到解决方案中 |
|||
|
|||
```bash |
|||
abp new Acme.IssueManagement -t module --add-to-solution-file |
|||
``` |
|||
|
|||
## 从特定版本创建解决方案 |
|||
|
|||
创建解决方案时, 它总是使用最新版本创建. 要从旧版本创建项目, 可以使用`--version`参数. |
|||
|
|||
* 使用v3.3.0版本创建解决方案, 包含Angular UI和Entity Framework Core. |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -t app -u angular -m none --database-provider ef -csf --version 3.3.0 |
|||
``` |
|||
|
|||
要获取ABP版本列表, 请查看以下链接: https://www.nuget.org/packages/Volo.Abp.Core/ |
|||
|
|||
## 从自定义模板创建 |
|||
|
|||
ABP CLI使用默认的[应用程序模板](https://github.com/abpframework/abp/tree/dev/templates/app)创建项目. 如果要从自定义模板创建新的解决方案, 可以使用参数`--template-source`. |
|||
|
|||
* 在`c:\MyProjects\templates\app`目录中使用模板, MVC UI, Entity Framework Core, 不创建移动端应用程序. |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -t app -u mvc --mobile none --database-provider ef --template-source "c:\MyProjects\templates\app" |
|||
``` |
|||
|
|||
* 除了此命令从URL `https://myabp.com/app-template.zip` 检索模板之外, 与上一个命令相同. |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -t app -u mvc --mobile none --database-provider ef --template-source https://myabp.com/app-template.zip |
|||
``` |
|||
|
|||
## 创建预览版本 |
|||
|
|||
ABP CLI始终使用最新版本. 要从预览(RC)版本创建解决方案, 请添加`--preview`参数. |
|||
|
|||
* 在新文件夹中创建项目, Blazor UI, Entity Framework Core, 不创建移动端应用程序, **使用最新版本**: |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -t app -u blazor --mobile none -csf --preview |
|||
``` |
|||
|
|||
## 选择数据库管理系统 |
|||
|
|||
默认的数据库管理系统是 `Entity Framework Core` / ` SQL Server`. 你可以通过使用`--database-management-system`参数选择DBMS. [可用的值](https://github.com/abpframework/abp/blob/dev/framework/src/Volo.Abp.Cli.Core/Volo/Abp/Cli/ProjectBuilding/Building/DatabaseManagementSystem.cs) 包括 `SqlServer`, `MySQL`, `SQLite`, `Oracle`, `Oracle-Devart`, `PostgreSQL`. 默认值是 `SqlServer`. |
|||
|
|||
* 在新文件夹中创建项目, Angular UI, **PostgreSQL** 数据库: |
|||
|
|||
```bash |
|||
abp new Acme.BookStore -u angular --database-management-system PostgreSQL -csf |
|||
``` |
|||
|
|||
## 使用静态HTTP端口 |
|||
|
|||
ABP CLI始终为项目分配随机端口. 如果需要保留默认端口并且创建解决方案始终使用相同的HTTP端口, 请添加参数`--no-random-port`. |
|||
|
|||
* 在新文件夹中创建项目, MVC UI, Entity Framework Core, **静态端口**: |
|||
|
|||
```bash |
|||
abp new Acme.BookStore --no-random-port -csf |
|||
``` |
|||
|
|||
## 引用本地ABP框架 |
|||
|
|||
在ABP解决方案中, 默认情况下从NuGet引用ABP库. 有时, 你需要在本地将ABP库引用到你的解决方案中. 这利于调试框架本身. 本地ABP框架的根目录必须有`Volo.Abp.sln`文件. 你可以将以下目录的内容复制到你的文件系统中 |
|||
|
|||
* MVC UI, Entity Framework Core, **引用本地的ABP库**: |
|||
|
|||
本地路径必须是ABP存储库的根目录. |
|||
如果`C:\source\abp\framework\Volo.Abp.sln`是你的框架解决方案的路径, 那么你必须设置`--abp-path`参数值为`C:\source\abp`. |
|||
|
|||
```bash |
|||
abp new Acme.BookStore --local-framework-ref --abp-path C:\source\abp |
|||
``` |
|||
|
|||
**输出**: |
|||
|
|||
如下所示, 引用本地ABP框架库项目. |
|||
|
|||
```xml |
|||
<ItemGroup> |
|||
<ProjectReference Include="C:\source\abp\framework\src\Volo.Abp.Autofac\Volo.Abp.Autofac.csproj" /> |
|||
<ProjectReference Include="C:\source\abp\framework\src\Volo.Abp.AspNetCore.Serilog\Volo.Abp.AspNetCore.Serilog.csproj" /> |
|||
<ProjectReference Include="C:\source\abp\framework\src\Volo.Abp.AspNetCore.Authentication.JwtBearer\Volo.Abp.AspNetCore.Authentication.JwtBearer.csproj" /> |
|||
<ProjectReference Include="..\Acme.BookStore.Application\Acme.BookStore.Application.csproj" /> |
|||
<ProjectReference Include="..\Acme.BookStore.HttpApi\Acme.BookStore.HttpApi.csproj" /> |
|||
<ProjectReference Include="..\Acme.BookStore.EntityFrameworkCore\Acme.BookStore.EntityFrameworkCore.csproj" /> |
|||
</ItemGroup> |
|||
``` |
|||
|
|||
## 另请参阅 |
|||
|
|||
* [ABP CLI文档](CLI.md) |
|||
@ -0,0 +1,99 @@ |
|||
# 部署到群集环境 |
|||
|
|||
本文档介绍了在将应用程序部署到**多个应用程序实例同时运行**的集群环境中时应注意的内容, 并解释了如何在基于ABP的应用程序中处理这些内容. |
|||
|
|||
> 无论你使用的是单体式应用程序还是微服务解决方案, 本文档均有效. 适用于一个流程. 应用程序可以是单体式web应用程序、微服务解决方案中的服务、控制台应用程序或其他类型的可执行进程. |
|||
> |
|||
> 例如, 如果你将应用程序部署到Kubernetes并把应用程序或服务在多个POD中运行, 那么应用程序或服务将在集群环境中运行. |
|||
|
|||
## 了解集群环境 |
|||
|
|||
> 如果你已经熟悉集群部署和负载均衡器, 可以跳过本节. |
|||
|
|||
### 单实例部署 |
|||
|
|||
考虑作为**单个实例**部署的应用程序, 如下图所示: |
|||
|
|||
 |
|||
|
|||
浏览器和其他客户端应用程序可以直接向应用程序发出HTTP请求. 你可以在客户端和应用程序之间放置一个web服务器(例如IIS或NGINX), 但仍有一个应用程序实例在单个服务器或容器中运行. 单实例的配置**限于规模**, 因为它在一台服务器上运行, 并且你受到服务器容量的限制. |
|||
|
|||
### 集群部署 |
|||
|
|||
**集群部署**是在一台或多台服务器上**同时运行**应用程序**多个实例**的方式. 通过这种方式, 不同的实例可以满足不同的请求, 并且可以通过在系统中添加新服务器来扩展. 下图显示了集群使用**负载均衡器**的典型实现: |
|||
|
|||
 |
|||
|
|||
### 负载均衡器 |
|||
|
|||
[负载均衡器](https://en.wikipedia.org/wiki/Load_balancing_(computing)) 有很多特性, 但它们基本上会将**传入的HTTP请求转发**给应用程序的实例, 并将响应返回给客户端应用程序. |
|||
|
|||
负载平衡器可以使用不同的算法来选择应用程序实例, 同时确定用于传递传入请求的应用程序实例. **循环**是最简单、最常用的算法之一. 请求被轮流传递到应用程序实例. 第一个实例得到第一个请求, 第二个实例得到第二个请求, 依此类推. 在所有实例都被使用之后, 它返回到第一个实例, 并且下一个请求的算法也是类似的. |
|||
|
|||
### 潜在问题 |
|||
|
|||
一旦应用程序的多个实例并行运行, 你应该仔细考虑以下内容: |
|||
|
|||
* 当你有多个实例时, 存储在应用程序 **内存中的任何状态(数据)** 都将成为问题. 存储在应用程序实例内存中的状态可能在下一个请求中不可用, 因为下一个请求将由不同的应用程序实例处理. 虽然有一些解决方案(比如粘性会话)可以解决这个问题, 但如果你想在集群、容器或云中运行应用程序, **最好将其设计为无状态**. |
|||
* **内存缓存** 是一种内存状态, 不应在集群应用程序中使用. 你应该使用**分布式缓存**. |
|||
* 你不应该在**本地文件系统**中存储应用程序所有实例都可以使用的数据. 不同的应用程序实例可能在不同的容器或服务器中运行, 并且它们可能无法访问同一个文件系统. 你可以使用**云或外部存储提供商**作为解决方案. |
|||
* 如果你有**后台工作者**或**作业队列管理器**, 则应小心, 因为多个实例可能会尝试执行同一作业或同时执行同一工作. 因此, 你可能会多次完成相同的工作, 或者在尝试访问和更改相同的资源时可能会出现很多错误. |
|||
|
|||
集群部署可能会有更多问题, 但这些是最常见的问题. ABP被设计为与集群部署场景兼容. 以下各节介绍了将基于ABP的应用程序部署到集群环境时应执行的操作. |
|||
|
|||
## 切换分布式缓存 |
|||
|
|||
ASP.NET Core提供了不同类型的缓存功能. [内存缓存](https://docs.microsoft.com/en-us/aspnet/core/performance/caching/memory)将对象存储在本地服务器的内存中, 并且仅对存储该对象的应用程序可用. 集群环境中的非粘性会话应使用[分布式缓存](https://docs.microsoft.com/en-us/aspnet/core/performance/caching/distributed), 除了一些特定场景(例如, 你可以将本地CSS文件缓存到内存中. 它是只读数据, 在所有应用程序实例中都是相同的. 出于性能原因, 你可以将其缓存到内存中, 而不会出现任何问题). |
|||
|
|||
[ABP的分布式缓存](../Caching.md)扩展了[ASP.NET Core的分布式缓存](https://docs.microsoft.com/en-us/aspnet/core/performance/caching/distributed)的基础设施. 默认情况下, 它在内存中工作. 当你要将应用程序部署到集群环境时, 应该配置实际的分布式缓存提供程序. |
|||
|
|||
> 即使应用程序不直接使用`IDistributedCache`, 也应该为集群部署配置缓存提供程序. 因为ABP框架和预构建的[应用程序模块](../Modules/Index.md)正在使用分布式缓存. |
|||
|
|||
ASP.NET Core提供了可以用作分布式缓存提供程序的多种集成, 如[Redis](https://redis.io/)和[NCache](https://www.alachisoft.com/ncache/). 你可以按照[微软文档](https://docs.microsoft.com/en-us/aspnet/core/performance/caching/distributed)了解如何在应用程序中使用它们. |
|||
|
|||
如果你决定使用Redis作为分布式缓存提供程序, **请遵循[ABP的Redis缓存集成文档](../Redis-Cache.md)** 了解将其安装到应用程序并配置Redis所需遵循的步骤. |
|||
|
|||
> 根据你在创建新ABP解决方案时的偏好, Redis缓存可能会预先安装在你的解决方案中. 例如, 如果你在MVC UI中选择了*Tiered*选项, Redis缓存将进行预装. 因为, 在这种情况下, 解决方案中有两个应用程序, 它们应该使用相同的缓存源来保持一致. |
|||
|
|||
## 使用合适的BLOB存储提供程序 |
|||
|
|||
如果你在[文件系统提供程序](../Blob-Storing-File-System.md)中使用了ABP的[BLOB存储](../Blob-Storing.md)功能, 则应该在集群环境中使用另一个提供程序, 因为文件系统提供程序使用应用程序的本地文件系统. |
|||
|
|||
[数据库BLOB提供程序](../Blob-Storing-Database)是最简单的方法, 因为它使用应用程序的主数据库(或另一个数据库, 如果你配置的话)来存储BLOB. 但是, 你应该记住, BLOB是大型对象, 可能会迅速增加数据库的大小. |
|||
|
|||
> [ABP商业版](https://commercial.abp.io/)启动解决方案模板预装了数据库BLOB提供程序, 并将BLOB存储在应用程序的数据库中. |
|||
|
|||
查看[BLOB Storing](../Blob-Storing.md)文档以查看所有可用的BLOB存储提供程序. |
|||
|
|||
## 配置后台作业 |
|||
|
|||
ABP的[后台作业系统](../Background-Jobs.md)将要在后台执行的任务进行排队. 后台作业队列是持久性的, 排队的任务能够保证执行(如果失败, 将重新尝试). |
|||
|
|||
ABP的默认后台作业管理器与集群环境兼容. 它使用[分布式锁](../Distributed-Locking.md)来确保一次只能在单个应用程序实例中执行作业. 请参阅下面的*配置分布式锁提供程序*部分, 了解如何为应用程序配置分布式锁提供程序, 以便默认后台作业管理器在集群环境中正常工作. |
|||
|
|||
如果不想使用分布式锁提供程序, 可以使用以下选项: |
|||
|
|||
* 停止所有应用程序实例中的后台作业管理器(将`AbpBackgroundJobOptions.IsJobExecutionEnabled`设置为`false`)只保留其中一个应用程序实例, 以便只有单个实例执行作业(而其他应用程序实例仍可以对作业进行排队). |
|||
* 在所有应用程序实例中停止后台作业管理器(将`AbpBackgroundJobOptions.IsJobExecutionEnabled`设置为`false`), 并创建一个专用的应用程序(可能是在自己的容器中运行的控制台应用程序或在后台运行的Windows服务)来执行所有后台作业. 如果你的后台作业占用大量系统资源(CPU、RAM或磁盘), 那么这是一个不错的选择, 这样你就可以将该后台应用程序部署到专用服务器上, 并且后台作业不会影响应用程序的性能. |
|||
|
|||
> 如果你使用的是外部后台作业集成(例如[Hangfire](../Background-Workers-Hangfire.md)或[Quartz](../Background-Workers-Quartz.md))而不是默认的后台作业管理器, 请参阅提供程序的文档, 了解如何为集群环境配置它. |
|||
|
|||
## 配置分布式锁提供程序 |
|||
|
|||
ABP通过[分布式锁](https://github.com/madelson/DistributedLock)库实现了一个抽象的分布式锁. 分布式锁用于控制多个应用程序对共享资源的并发访问, 以防止由于并发写入而导致资源损坏. ABP框架和一些预构建的[应用程序模块](../Modules/Index.md)出于一些原因正在使用分布式锁. |
|||
|
|||
但是, 分布式锁系统默认在进程中工作. 这意味着它实际上不是分布式的, 除非配置分布式锁提供程序. 因此, 如果尚未配置应用程序的提供程序, 请按照[分布式锁](../Distributed-Locking.md)文档为其配置提供程序. |
|||
|
|||
## 实现后台工作者 |
|||
|
|||
ASP.NET Core[托管服务](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/host/hosted-services), ABP提供[后台工作者](../Background-Workers.md)在应用程序的后台线程中执行任务. |
|||
|
|||
如果你的应用程序有在后台运行的任务, 你应该注意它们在集群环境中的行为, 尤其是在后台任务使用相同资源的情况下. 你应该设计后台任务, 以便它们在集群环境中继续正常工作. |
|||
|
|||
假设SaaS应用程序中的后台工作者检查用户订阅, 并在订阅续订日期临近时发送电子邮件. 如果后台任务在多个应用程序实例中运行, 可能会多次向某些用户发送同一封电子邮件, 这会影响他们. |
|||
|
|||
我们建议你使用以下方法之一来解决此问题: |
|||
|
|||
* 实现你的后台工作者, 以便他们在集群环境中工作时不会出现任何问题. 使用[分布式锁](../Distributed-Locking.md)来确保并发控制是一种方法. 应用程序实例中的后台工作者可能会处理分布式锁, 因此其他应用程序实例中的工作者将等待该锁. 这样, 只有一个工作者在实际工作, 而其他的则在等待. 如果你实现了这一点, 你的后台工作者就可以安全地运行, 不必关心应用程序是如何部署的. |
|||
* 停止所有应用程序实例中的后台工作者(将`AbpBackgroundWorkerOptions.IsEnabled`设置为`false`), 只保留其中一个应用程序实例, 因此只有单个实例运行这些后台工作者. |
|||
* 停止所有应用程序实例中的后台工作者(将`AbpBackgroundWorkerOptions.IsEnabled`设置为`false`), 并创建一个专用的应用程序(可能是在自己的容器中运行的控制台应用程序或在后台运行的Windows服务)来执行所有后台任务. 如果你的后台工作者消耗大量系统资源(CPU、RAM或磁盘), 那么这是一个不错的选择, 这样你就可以将该后台应用程序部署到专用服务器上, 并且你的后台任务不会影响应用程序的性能. |
|||
@ -0,0 +1,9 @@ |
|||
# 部署 |
|||
|
|||
部署ABP应用程序与部署其他.NET或ASP.NET Core应用程序并没有什么不同. 你可以将其部署到云服务提供商(例如Azure、AWS、Google)或内部部署服务器、IIS或任何其他web服务器. ABP的文档中没有太多关于部署的信息. 你可以参考提供商的文档. |
|||
|
|||
但是, 在部署应用程序时, 有些主题是你应该注意的. 其中大多数是一般的软件部署注意事项, 但你应该了解如何在基于ABP的应用程序中处理它们. 我们为此准备了指南, 建议你在设计部署配置之前仔细阅读这些指南. |
|||
|
|||
## 指南 |
|||
|
|||
* [部署到群集环境](Clustered-Environment.md): 讲解了当你希望同时运行应用程序的多个实例时, 如何来配置应用程序. |
|||
@ -0,0 +1,110 @@ |
|||
# 分布式锁 |
|||
分布式锁是一种管理多个应用程序访问同一资源的技术. 主要目的是同一时间只允许多个应用程序中的一个访问资源. 否则, 从不同的应用程序访问同一对象可能会破坏资源. |
|||
|
|||
> ABP当前的分布式锁实现基于[DistributedLock](https://github.com/madelson/DistributedLock)库. |
|||
|
|||
## 安装 |
|||
|
|||
你可以打开一个命令行终端并输入以下命令来安装[Volo.Abp.DistributedLocking](https://www.nuget.org/packages/Volo.Abp.DistributedLocking)到你的项目中: |
|||
|
|||
````bash |
|||
abp add-package Volo.Abp.DistributedLocking |
|||
```` |
|||
|
|||
这个库提供了使用分布式锁系统所需的API, 但是, 在使用它之前, 你应该配置一个提供程序. |
|||
|
|||
### 配置一个提供程序 |
|||
|
|||
[DistributedLock](https://github.com/madelson/DistributedLock)库对[Redis](https://github.com/madelson/DistributedLock/blob/master/docs/DistributedLock.Redis.md)和[ZooKeeper](https://github.com/madelson/DistributedLock/blob/master/docs/DistributedLock.ZooKeeper.md)提供[多种实现](https://github.com/madelson/DistributedLock#implementations). |
|||
|
|||
例如, 如果你想使用[Redis provider](https://github.com/madelson/DistributedLock/blob/master/docs/DistributedLock.Redis.md), 你应该将[DistributedLock.Redis](https://www.nuget.org/packages/DistributedLock.Redis) NuGet包添加到项目中, 然后将以下代码添加到ABP[模块](Module-Development-Basics.md)类的`ConfigureServices`方法中: |
|||
|
|||
````csharp |
|||
using Medallion.Threading; |
|||
using Medallion.Threading.Redis; |
|||
|
|||
namespace AbpDemo |
|||
{ |
|||
[DependsOn( |
|||
typeof(AbpDistributedLockingModule) |
|||
//If you have the other dependencies, you should do here |
|||
)] |
|||
public class MyModule : AbpModule |
|||
{ |
|||
public override void ConfigureServices(ServiceConfigurationContext context) |
|||
{ |
|||
var configuration = context.Services.GetConfiguration(); |
|||
|
|||
context.Services.AddSingleton<IDistributedLockProvider>(sp => |
|||
{ |
|||
var connection = ConnectionMultiplexer |
|||
.Connect(configuration["Redis:Configuration"]); |
|||
return new |
|||
RedisDistributedSynchronizationProvider(connection.GetDatabase()); |
|||
}); |
|||
} |
|||
} |
|||
} |
|||
```` |
|||
|
|||
此代码从[配置](Configuration.md)获取Redis连接字符串, 因此你可以将以下行添加到`appsettings.json`文件: |
|||
|
|||
````json |
|||
"Redis": { |
|||
"Configuration": "127.0.0.1" |
|||
} |
|||
```` |
|||
|
|||
## 使用 |
|||
|
|||
有两种方法可以使用分布式锁API: ABP的`IAbpDistributedLock`抽象和[DistributedLock](https://github.com/madelson/DistributedLock)库的API. |
|||
|
|||
### 使用IAbpDistributedLock服务 |
|||
|
|||
`IAbpDistributedLock`是ABP框架提供的一个用于简单使用分布式锁的服务. |
|||
|
|||
**实例: 使用`IAbpDistributedLock.TryAcquireAsync`方法** |
|||
|
|||
````csharp |
|||
using Volo.Abp.DistributedLocking; |
|||
|
|||
namespace AbpDemo |
|||
{ |
|||
public class MyService : ITransientDependency |
|||
{ |
|||
private readonly IAbpDistributedLock _distributedLock; |
|||
public MyService(IAbpDistributedLock distributedLock) |
|||
{ |
|||
_distributedLock = distributedLock; |
|||
} |
|||
|
|||
public async Task MyMethodAsync() |
|||
{ |
|||
await using (var handle = |
|||
await _distributedLock.TryAcquireAsync("MyLockName")) |
|||
{ |
|||
if (handle != null) |
|||
{ |
|||
// your code that access the shared resource |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
```` |
|||
|
|||
`TryAcquireAsync`可能无法获取锁. 如果无法获取锁, 则返回`null`. 在这种情况下, 你不应该访问资源. 如果句柄不为`null`, 则表示你已获得锁, 并且可以安全地访问资源. |
|||
|
|||
`TryAcquireAsync`方法拥有以下参数: |
|||
|
|||
* `name` (`string`, 必须): 锁的唯一名称. 不同的锁命名用于访问不同的资源. |
|||
* `timeout` (`TimeSpan`): 等待获取锁的超时值. 默认值为`TimeSpan.Zero`, 这意味着如果锁已经被另一个应用程序拥有, 它不会等待. |
|||
* `cancellationToken`: 取消令牌可在触发后取消操作. |
|||
|
|||
### 使用DistributedLock库的API |
|||
|
|||
ABP的`IAbpDistributedLock`服务非常有限, 主要用于ABP框架的内部使用. 对于你自己的应用程序, 可以使用DistributedLock库自己的API. 参见[文档](https://github.com/madelson/DistributedLock)详细信息. |
|||
|
|||
## Volo.Abp.DistributedLocking.Abstractions库 |
|||
|
|||
如果你正在构建一个可重用的库或应用程序模块, 那么对于作为单个实例运行的简单应用程序, 你可能不希望为模块带来额外的依赖关系. 在这种情况下, 你的库可以依赖于[Volo.Abp.DistributedLocking.Abstractions](https://nuget.org/packages/Volo.Abp.DistributedLocking.Abstractions)库, 它定义了`IAbpDistributedLock`服务, 并将其在进程内实现(实际上不是分布式的). 通过这种方式, 你的库可以在作为单个实例运行的应用程序中正常运行(没有分布式锁提供程序依赖项). 如果应用程序部署到[集群环境](Deployment/Clustered-Environment.md), 那么应用程序开发人员应该安装一个真正的分布式提供程序, 如*安装*部分所述. |
|||
@ -0,0 +1,768 @@ |
|||
# 自动化测试 |
|||
|
|||
## 介绍 |
|||
|
|||
ABP框架的设计考虑了可测试性. 有一些不同级别的自动化测试: |
|||
|
|||
* **单元测试**: 通常只测试一个类(或者一起测试几个类). 这些测试会很快. 然而, 你通常需要处理对服务依赖项的模拟. |
|||
* **集成测试**: 你通常会测试一个服务, 但这一次你不会模拟基本的基础设施和服务, 以查看它们是否正确地协同工作. |
|||
* **用户界面测试**: 测试应用程序的UI, 就像用户与应用程序交互一样. |
|||
|
|||
### 单元测试 vs 集成测试 |
|||
|
|||
与单元测试相比, 集成测试有一些显著的**优势**: |
|||
|
|||
* **编写更加简单** 因为你不需要模拟和处理依赖关系. |
|||
* 你的测试代码运行于所有真正的服务和基础设施(包括数据库映射和查询), 因此它更接近于**真正的应用程序测试**. |
|||
|
|||
同时它们有一些缺点: |
|||
|
|||
* 与单元测试相比, 它们**更慢**, 因为所有的基础设施都准备好了测试用例. |
|||
* 服务中的一个bug可能会导致多个测试用例失败, 因此在某些情况下, 可能会**更难找到真正的问题**. |
|||
|
|||
我们建议混合使用: 在必要的地方编写单元测试或集成测试, 并且有效的编写和维护它. |
|||
|
|||
## 应用程序启动模板 |
|||
|
|||
测试基础设施提供[应用程序启动模板](Startup-Templates/Application.md) , 并已经正确安装和配置. |
|||
|
|||
### 测试项目 |
|||
|
|||
请参见Visual Studio中的以下解决方案: |
|||
|
|||
 |
|||
|
|||
按层级系统分为多个测试项目: |
|||
|
|||
* `Domain.Tests` 用于测试领域层对象 (例如[领域服务](Domain-Services.md) 和 [实体](Entities.md)). |
|||
* `Application.Tests` 用于测试应用层对象 (例如[应用服务](Application-Services.md)). |
|||
* `EntityFrameworkCore.Tests` 用于测试你的自定义仓储实现或EF Core映射(如果你使用其他[数据访问](Data-Access.md))的话, 该项目将有所不同). |
|||
* `Web.Tests` 用于测试UI层(如页面、控制器和视图组件). 该项目仅适用于MVC / Razor页面应用程序. |
|||
* `TestBase` 包含一些由其他项目共享/使用的类. |
|||
|
|||
> `HttpApi.Client.ConsoleTestApp` 不是自动化测试的应用程序. 它是一个示例的控制台应用程序, 展示了如何从.NET控制台应用程序中调用HTTP API. |
|||
|
|||
以下的部分将介绍这些项目中包含的基类和其他基础设施. |
|||
|
|||
### 测试基础设施 |
|||
|
|||
解决方案中已经安装了以下库: |
|||
|
|||
* [xUnit](https://xunit.net/) 作为测试框架. |
|||
* [NSubstitute](https://nsubstitute.github.io/) 用于模拟. |
|||
* [Shouldly](https://github.com/shouldly/shouldly) 用于断言. |
|||
|
|||
虽然你可以用自己喜欢的工具替换它们, 但本文档和示例将基于这些工具. |
|||
|
|||
## 测试资源管理器 |
|||
|
|||
你可以在Visual Studio中使用测试资源管理器查看和运行测试. 其他IDE, 请参阅它们自己的文档. |
|||
|
|||
### 打开测试资源管理器 |
|||
|
|||
打开*测试*菜单下的*测试资源管理器*(如果尚未打开): |
|||
|
|||
 |
|||
|
|||
### 运行测试 |
|||
|
|||
然后, 你可以单击在视图中运行所有测试或运行按钮来运行测试. 初始启动模板为你提供了一些测试用例: |
|||
|
|||
 |
|||
|
|||
### 并行运行测试 |
|||
|
|||
支持并行运行测试. **强烈建议**并行运行所有测试, 这比逐个运行测试要快得多. |
|||
|
|||
要启用它, 请单击设置(齿轮)按钮附近的插入符号图标, 然后选择*并行运行测试*. |
|||
|
|||
 |
|||
|
|||
## 单元测试 |
|||
|
|||
对于单元测试, 不需要太多的配置. 通常会实例化你的类, 并对要测试的对象提供一些预先配置的模拟对象. |
|||
|
|||
### 没有依赖项的类 |
|||
|
|||
要测试的类没有依赖项是最简单的情况, 你可以直接实例化类, 调用其方法并做出断言. |
|||
|
|||
#### 示例: 测试实体 |
|||
|
|||
假设你有一个 `Issue` [实体](Entities.md), 如下所示: |
|||
|
|||
````csharp |
|||
using System; |
|||
using Volo.Abp.Domain.Entities; |
|||
|
|||
namespace MyProject.Issues |
|||
{ |
|||
public class Issue : AggregateRoot<Guid> |
|||
{ |
|||
public string Title { get; set; } |
|||
public string Description { get; set; } |
|||
public bool IsLocked { get; set; } |
|||
public bool IsClosed { get; private set; } |
|||
public DateTime? CloseDate { get; private set; } |
|||
|
|||
public void Close() |
|||
{ |
|||
IsClosed = true; |
|||
CloseDate = DateTime.UtcNow; |
|||
} |
|||
|
|||
public void Open() |
|||
{ |
|||
if (!IsClosed) |
|||
{ |
|||
return; |
|||
} |
|||
|
|||
if (IsLocked) |
|||
{ |
|||
throw new IssueStateException("You can not open a locked issue!"); |
|||
} |
|||
|
|||
IsClosed = true; |
|||
CloseDate = null; |
|||
} |
|||
} |
|||
} |
|||
|
|||
```` |
|||
|
|||
请注意, `IsClosed`和`CloseDate`属性具有私有setter, 可以使用`Open()`和`Close()`方法强制执行某些业务逻辑: |
|||
|
|||
* 无论何时关闭issue, `CloseDate`都应设置为[当前时间](Timing.md). |
|||
* 如果issue被锁定, 则无法重新打开. 如果它被重新打开, `CloseDate`应该设置为`null`. |
|||
|
|||
由于`Issue`实体是领域层的一部分, 所以我们应该在`Domain.Tests`项目中测试它. 在`Domain.Tests`项目中创建一个`Issue_Tests`类: |
|||
|
|||
````csharp |
|||
using Shouldly; |
|||
using Xunit; |
|||
|
|||
namespace MyProject.Issues |
|||
{ |
|||
public class Issue_Tests |
|||
{ |
|||
[Fact] |
|||
public void Should_Set_The_CloseDate_Whenever_Close_An_Issue() |
|||
{ |
|||
// Arrange |
|||
|
|||
var issue = new Issue(); |
|||
issue.CloseDate.ShouldBeNull(); // null at the beginning |
|||
|
|||
// Act |
|||
|
|||
issue.Close(); |
|||
|
|||
// Assert |
|||
|
|||
issue.IsClosed.ShouldBeTrue(); |
|||
issue.CloseDate.ShouldNotBeNull(); |
|||
} |
|||
} |
|||
} |
|||
```` |
|||
|
|||
这个测试遵循AAA(Arrange-Act-Assert)模式: |
|||
|
|||
* **Arrange** 部分创建一个`Issue`实体, 并确保`CloseDate`在初始值为`null`. |
|||
* **Act** 部分执行我们想要测试的方法. |
|||
* **Assert** 部分检查`Issue`属性是否与我们预期的相同. |
|||
|
|||
`[Fact]`属性由[xUnit](https://xunit.net/)并将方法标记为测试方法. `Should...`扩展方法由[Shouldly](https://github.com/shouldly/shouldly)提供. 你可以直接使用xUnit中的`Assert`类, 使用Shouldly让它更舒适、更直观. |
|||
|
|||
当你执行测试时, 你将看到它成功通过: |
|||
|
|||
 |
|||
|
|||
让我们再添加两种测试方法: |
|||
|
|||
````csharp |
|||
[Fact] |
|||
public void Should_Allow_To_ReOpen_An_Issue() |
|||
{ |
|||
// Arrange |
|||
|
|||
var issue = new Issue(); |
|||
issue.Close(); |
|||
|
|||
// Act |
|||
|
|||
issue.Open(); |
|||
|
|||
// Assert |
|||
|
|||
issue.IsClosed.ShouldBeFalse(); |
|||
issue.CloseDate.ShouldBeNull(); |
|||
} |
|||
|
|||
[Fact] |
|||
public void Should_Not_Allow_To_ReOpen_A_Locked_Issue() |
|||
{ |
|||
// Arrange |
|||
|
|||
var issue = new Issue(); |
|||
issue.Close(); |
|||
issue.IsLocked = true; |
|||
|
|||
// Act & Assert |
|||
|
|||
Assert.Throws<IssueStateException>(() => |
|||
{ |
|||
issue.Open(); |
|||
}); |
|||
} |
|||
```` |
|||
|
|||
`Assert.Throws` 检查执行的代码是否匹配引发的异常. |
|||
|
|||
> 有关这些库的更多信息, 请参阅xUnit & Shoudly的文档. |
|||
|
|||
### 具有依赖项的类 |
|||
|
|||
如果你的服务中有依赖项, 并且你想对该服务进行单元测试, 那么你需要模拟这些依赖项. |
|||
|
|||
#### 示例: 测试领域服务 |
|||
|
|||
假设你有一个`IssueManager` [领域服务](Domain-Services.md), 定义如下: |
|||
|
|||
````csharp |
|||
using System; |
|||
using System.Threading.Tasks; |
|||
using Volo.Abp; |
|||
using Volo.Abp.Domain.Services; |
|||
|
|||
namespace MyProject.Issues |
|||
{ |
|||
public class IssueManager : DomainService |
|||
{ |
|||
public const int MaxAllowedOpenIssueCountForAUser = 3; |
|||
|
|||
private readonly IIssueRepository _issueRepository; |
|||
|
|||
public IssueManager(IIssueRepository issueRepository) |
|||
{ |
|||
_issueRepository = issueRepository; |
|||
} |
|||
|
|||
public async Task AssignToUserAsync(Issue issue, Guid userId) |
|||
{ |
|||
var issueCount = await _issueRepository.GetIssueCountOfUserAsync(userId); |
|||
|
|||
if (issueCount >= MaxAllowedOpenIssueCountForAUser) |
|||
{ |
|||
throw new BusinessException( |
|||
code: "IM:00392", |
|||
message: $"You can not assign more" + |
|||
$"than {MaxAllowedOpenIssueCountForAUser} issues to a user!" |
|||
); |
|||
} |
|||
|
|||
issue.AssignedUserId = userId; |
|||
} |
|||
} |
|||
} |
|||
```` |
|||
|
|||
`IssueManager`依赖于`IssueRepository`服务, 在本例中将模拟该服务. |
|||
|
|||
**业务逻辑**: 示例`AssignToUserAsync`不允许向用户分配超过3个issue (`MaxAllowedOpenIssueCountForAUser`常量). 在这种情况下, 如果要分配issue, 首先需要取消现有issue的分配. |
|||
|
|||
下面的测试用例给出一个有效的赋值: |
|||
|
|||
````csharp |
|||
using System; |
|||
using System.Threading.Tasks; |
|||
using NSubstitute; |
|||
using Shouldly; |
|||
using Volo.Abp; |
|||
using Xunit; |
|||
|
|||
namespace MyProject.Issues |
|||
{ |
|||
public class IssueManager_Tests |
|||
{ |
|||
[Fact] |
|||
public async Task Should_Assign_An_Issue_To_A_User() |
|||
{ |
|||
// Arrange |
|||
|
|||
var userId = Guid.NewGuid(); |
|||
|
|||
var fakeRepo = Substitute.For<IIssueRepository>(); |
|||
fakeRepo.GetIssueCountOfUserAsync(userId).Returns(1); |
|||
|
|||
var issueManager = new IssueManager(fakeRepo); |
|||
|
|||
var issue = new Issue(); |
|||
|
|||
// Act |
|||
|
|||
await issueManager.AssignToUserAsync(issue, userId); |
|||
|
|||
//Assert |
|||
|
|||
issue.AssignedUserId.ShouldBe(userId); |
|||
await fakeRepo.Received(1).GetIssueCountOfUserAsync(userId); |
|||
} |
|||
} |
|||
} |
|||
```` |
|||
|
|||
* `Substitute.For<IIssueRepository>` 创建一个模拟(假)对象, 该对象被传递到`IssueManager`构造函数中. |
|||
* `fakeRepo.GetIssueCountOfUserAsync(userId).Returns(1)` 确保仓储中的`GetIssueContofuseRasync`方法返回`1`. |
|||
* `issueManager.AssignToUserAsync` 不会引发任何异常, 因为仓储统计当前分配的issue数量并且返回`1`. |
|||
* `issue.AssignedUserId.ShouldBe(userId);` 行检查`AssignedUserId`的值是否正确. |
|||
* `await fakeRepo.Received(1).GetIssueCountOfUserAsync(userId);` 检查 `IssueManager` 实际只调用了 `GetIssueCountOfUserAsync` 方法一次. |
|||
|
|||
让我们添加第二个测试, 看看它是否能阻止将issue分配给超过分配数量的用户: |
|||
|
|||
````csharp |
|||
[Fact] |
|||
public async Task Should_Not_Allow_To_Assign_Issues_Over_The_Limit() |
|||
{ |
|||
// Arrange |
|||
|
|||
var userId = Guid.NewGuid(); |
|||
|
|||
var fakeRepo = Substitute.For<IIssueRepository>(); |
|||
fakeRepo |
|||
.GetIssueCountOfUserAsync(userId) |
|||
.Returns(IssueManager.MaxAllowedOpenIssueCountForAUser); |
|||
|
|||
var issueManager = new IssueManager(fakeRepo); |
|||
|
|||
// Act & Assert |
|||
|
|||
var issue = new Issue(); |
|||
|
|||
await Assert.ThrowsAsync<BusinessException>(async () => |
|||
{ |
|||
await issueManager.AssignToUserAsync(issue, userId); |
|||
}); |
|||
|
|||
issue.AssignedUserId.ShouldBeNull(); |
|||
await fakeRepo.Received(1).GetIssueCountOfUserAsync(userId); |
|||
} |
|||
```` |
|||
|
|||
> 有关模拟的更多信息, 请参阅[NSubstitute](https://nsubstitute.github.io/)文档. |
|||
|
|||
模拟单个依赖项相对容易. 但是, 当依赖关系增长时, 设置测试对象和模拟所有依赖关系变得越来越困难. 请参阅不需要模拟依赖项的*Integration Tests*部分. |
|||
|
|||
### 提示: 共享测试类构造函数 |
|||
|
|||
[xUnit](https://xunit.net/) 为每个测试方法创建一个**新测试类实例**(本例中为`IssueManager_Tests`). 因此, 你可以将一些*Arrange*代码移动到构造函数中, 以减少代码重复. 构造函数将针对每个测试用例执行, 并且不会相互影响, 即使它们是并行工作. |
|||
|
|||
**示例: 重构`IssueManager_Tests`以减少代码重复** |
|||
|
|||
````csharp |
|||
using System; |
|||
using System.Threading.Tasks; |
|||
using NSubstitute; |
|||
using Shouldly; |
|||
using Volo.Abp; |
|||
using Xunit; |
|||
|
|||
namespace MyProject.Issues |
|||
{ |
|||
public class IssueManager_Tests |
|||
{ |
|||
private readonly Guid _userId; |
|||
private readonly IIssueRepository _fakeRepo; |
|||
private readonly IssueManager _issueManager; |
|||
private readonly Issue _issue; |
|||
|
|||
public IssueManager_Tests() |
|||
{ |
|||
_userId = Guid.NewGuid(); |
|||
_fakeRepo = Substitute.For<IIssueRepository>(); |
|||
_issueManager = new IssueManager(_fakeRepo); |
|||
_issue = new Issue(); |
|||
} |
|||
|
|||
[Fact] |
|||
public async Task Should_Assign_An_Issue_To_A_User() |
|||
{ |
|||
// Arrange |
|||
_fakeRepo.GetIssueCountOfUserAsync(_userId).Returns(1); |
|||
|
|||
// Act |
|||
await _issueManager.AssignToUserAsync(_issue, _userId); |
|||
|
|||
//Assert |
|||
_issue.AssignedUserId.ShouldBe(_userId); |
|||
await _fakeRepo.Received(1).GetIssueCountOfUserAsync(_userId); |
|||
} |
|||
|
|||
[Fact] |
|||
public async Task Should_Not_Allow_To_Assign_Issues_Over_The_Limit() |
|||
{ |
|||
// Arrange |
|||
_fakeRepo |
|||
.GetIssueCountOfUserAsync(_userId) |
|||
.Returns(IssueManager.MaxAllowedOpenIssueCountForAUser); |
|||
|
|||
// Act & Assert |
|||
await Assert.ThrowsAsync<BusinessException>(async () => |
|||
{ |
|||
await _issueManager.AssignToUserAsync(_issue, _userId); |
|||
}); |
|||
|
|||
_issue.AssignedUserId.ShouldBeNull(); |
|||
await _fakeRepo.Received(1).GetIssueCountOfUserAsync(_userId); |
|||
} |
|||
} |
|||
} |
|||
```` |
|||
|
|||
> 保持测试代码整洁, 以创建可维护的测试组件. |
|||
|
|||
## 集成测试 |
|||
|
|||
> 你还可以按照[Web应用程序开发教程](Tutorials/Part-1.md)学习开发全栈应用程序, 包括集成测试. |
|||
|
|||
### 集成测试基础 |
|||
|
|||
ABP为编写集成测试提供了完整的基础设施. 所有ABP基础设施和服务都将在你的测试中执行. 应用程序启动模板附带了为你预先配置的必要基础设施; |
|||
|
|||
#### 数据库 |
|||
|
|||
启动模板使用EF Core配置**内存中的SQLite**数据库(对于MongoDB, 它使用[Mongo2Go](https://github.com/Mongo2Go/Mongo2Go)). 因此, 所有配置和查询都是针对真实数据库执行的, 你甚至可以测试数据库事务. |
|||
|
|||
使用内存中的SQLite数据库有两个主要优点: |
|||
|
|||
* 它比外部DBMS更快. |
|||
* 它会为每个测试用例创建一个**新的数据库**, 这样测试就不会相互影响. |
|||
|
|||
> **提示**: 不要将EF Core的内存数据库用于高级集成测试. 它不是一个真正的DBMS, 在细节上有很多不同. 例如, 它不支持事务和回滚场景, 因此无法真正测试失败的场景. 另一方面, 内存中的SQLite是一个真正的DBMS, 支持SQL数据库的基本功能. |
|||
|
|||
### 种子数据 |
|||
|
|||
针对空数据库编写测试是不现实的. 在大多数情况下, 需要在数据库中保存一些初始数据. 例如, 如果你编写了一个查询、更新和删除产品的测试类, 那么在执行测试用例之前, 在数据库中有一些产品数据会很有帮助. |
|||
|
|||
ABP的[种子数据](Data-Seeding.md)系统是一种强大的初始化数据的方法. 应用程序启动模板在`.TestBase`项目中有一个*YourProject*TestDataSeedContributor类. 你可以在其中添加, 以获得可用于每个测试方法的初始数据. |
|||
|
|||
**示例: 创建一些Issue作为种子数据** |
|||
|
|||
````csharp |
|||
using System.Threading.Tasks; |
|||
using MyProject.Issues; |
|||
using Volo.Abp.Data; |
|||
using Volo.Abp.DependencyInjection; |
|||
|
|||
namespace MyProject |
|||
{ |
|||
public class MyProjectTestDataSeedContributor |
|||
: IDataSeedContributor, ITransientDependency |
|||
{ |
|||
private readonly IIssueRepository _issueRepository; |
|||
|
|||
public MyProjectTestDataSeedContributor(IIssueRepository issueRepository) |
|||
{ |
|||
_issueRepository = issueRepository; |
|||
} |
|||
|
|||
public async Task SeedAsync(DataSeedContext context) |
|||
{ |
|||
await _issueRepository.InsertAsync( |
|||
new Issue |
|||
{ |
|||
Title = "Test issue one", |
|||
Description = "Test issue one description", |
|||
AssignedUserId = TestData.User1Id |
|||
}); |
|||
|
|||
await _issueRepository.InsertAsync( |
|||
new Issue |
|||
{ |
|||
Title = "Test issue two", |
|||
Description = "Test issue two description", |
|||
AssignedUserId = TestData.User1Id |
|||
}); |
|||
|
|||
await _issueRepository.InsertAsync( |
|||
new Issue |
|||
{ |
|||
Title = "Test issue three", |
|||
Description = "Test issue three description", |
|||
AssignedUserId = TestData.User1Id |
|||
}); |
|||
|
|||
await _issueRepository.InsertAsync( |
|||
new Issue |
|||
{ |
|||
Title = "Test issue four", |
|||
Description = "Test issue four description", |
|||
AssignedUserId = TestData.User2Id |
|||
}); |
|||
} |
|||
} |
|||
} |
|||
```` |
|||
|
|||
还创建了一个静态类来存储用户的 `Id`: |
|||
|
|||
````csharp |
|||
using System; |
|||
|
|||
namespace MyProject |
|||
{ |
|||
public static class TestData |
|||
{ |
|||
public static Guid User1Id = Guid.Parse("41951813-5CF9-4204-8B18-CD765DBCBC9B"); |
|||
public static Guid User2Id = Guid.Parse("2DAB4460-C21B-4925-BF41-A52750A9B999"); |
|||
} |
|||
} |
|||
```` |
|||
|
|||
通过这种方式, 我们可以使用这些已知Issue和用户的`Id`来运行测试. |
|||
|
|||
### 示例: 测试领域服务 |
|||
|
|||
`AbpIntegratedTest<T>`类 (定义在[Volo.Abp.TestBase](https://www.nuget.org/packages/Volo.Abp.TestBase)) 用于编写集成到ABP框架的测试. `T`是用于设置和初始化应用程序的根模块的类型. |
|||
|
|||
应用程序启动模板在每个测试项目中都有基类, 因此你可以从这些基类派生, 以使其更简单. |
|||
|
|||
`IssueManager`测试将被重写成集成测试 |
|||
|
|||
````csharp |
|||
using System.Threading.Tasks; |
|||
using Shouldly; |
|||
using Volo.Abp; |
|||
using Xunit; |
|||
|
|||
namespace MyProject.Issues |
|||
{ |
|||
public class IssueManager_Integration_Tests : MyProjectDomainTestBase |
|||
{ |
|||
private readonly IssueManager _issueManager; |
|||
private readonly Issue _issue; |
|||
|
|||
public IssueManager_Integration_Tests() |
|||
{ |
|||
_issueManager = GetRequiredService<IssueManager>(); |
|||
_issue = new Issue |
|||
{ |
|||
Title = "Test title", |
|||
Description = "Test description" |
|||
}; |
|||
} |
|||
|
|||
[Fact] |
|||
public async Task Should_Not_Allow_To_Assign_Issues_Over_The_Limit() |
|||
{ |
|||
// Act & Assert |
|||
await Assert.ThrowsAsync<BusinessException>(async () => |
|||
{ |
|||
await _issueManager.AssignToUserAsync(_issue, TestData.User1Id); |
|||
}); |
|||
|
|||
_issue.AssignedUserId.ShouldBeNull(); |
|||
} |
|||
|
|||
[Fact] |
|||
public async Task Should_Assign_An_Issue_To_A_User() |
|||
{ |
|||
// Act |
|||
await _issueManager.AssignToUserAsync(_issue, TestData.User2Id); |
|||
|
|||
//Assert |
|||
_issue.AssignedUserId.ShouldBe(TestData.User2Id); |
|||
} |
|||
} |
|||
} |
|||
```` |
|||
|
|||
* 第一个测试方法将issue分配给User1, 其中User1已经分配了种子数据代码中的3个issue. 因此, 它抛出了一个`BusinessException`. |
|||
* 第二种测试方法将issue分配给User2, User2只分配了一个issue. 因此, 该方法成功了. |
|||
|
|||
这个类通常位于`.Domain.Tests`项目中, 因为它测试位于`.Domain`项目中的类. 它派生自`MyProjectDomainTestBase`, 并已经为正确运行测试进行了配置. |
|||
|
|||
编写这样一个集成测试类非常简单. 另一个好处是, 在以后向`IssueManager`类添加另一个依赖项时, 不需要更改测试类. |
|||
|
|||
### 示例: 测试应用服务 |
|||
|
|||
测试[应用服务](Application-Services.md)并没有太大的不同. 假设你已经创建了一个`IssueAppService`, 定义如下: |
|||
|
|||
````csharp |
|||
using System.Collections.Generic; |
|||
using System.Threading.Tasks; |
|||
using Volo.Abp.Application.Services; |
|||
|
|||
namespace MyProject.Issues |
|||
{ |
|||
public class IssueAppService : ApplicationService, IIssueAppService |
|||
{ |
|||
private readonly IIssueRepository _issueRepository; |
|||
|
|||
public IssueAppService(IIssueRepository issueRepository) |
|||
{ |
|||
_issueRepository = issueRepository; |
|||
} |
|||
|
|||
public async Task<List<IssueDto>> GetListAsync() |
|||
{ |
|||
var issues = await _issueRepository.GetListAsync(); |
|||
|
|||
return ObjectMapper.Map<List<Issue>, List<IssueDto>>(issues); |
|||
} |
|||
} |
|||
} |
|||
```` |
|||
|
|||
*(假设你还定义了`IIssueAppService`和`IssueDto`, 并在`Issue`和`IssueDto`之间创建了[对象映射](Object-To-Object-Mapping.md))* |
|||
|
|||
现在, 你可以在`.Application.Tests`项目中编写一个测试类: |
|||
|
|||
````csharp |
|||
using System.Threading.Tasks; |
|||
using Shouldly; |
|||
using Xunit; |
|||
|
|||
namespace MyProject.Issues |
|||
{ |
|||
public class IssueAppService_Tests : MyProjectApplicationTestBase |
|||
{ |
|||
private readonly IIssueAppService _issueAppService; |
|||
|
|||
public IssueAppService_Tests() |
|||
{ |
|||
_issueAppService = GetRequiredService<IIssueAppService>(); |
|||
} |
|||
|
|||
[Fact] |
|||
public async Task Should_Get_All_Issues() |
|||
{ |
|||
//Act |
|||
var issueDtos = await _issueAppService.GetListAsync(); |
|||
|
|||
//Assert |
|||
issueDtos.Count.ShouldBeGreaterThan(0); |
|||
} |
|||
} |
|||
} |
|||
```` |
|||
|
|||
就这么简单. 此测试方法测试的所有内容, 包括应用服务、EF Core映射、对象到对象映射和仓储实现. 通过这种方式, 你可以完全测试解决方案的应用层和领域层. |
|||
|
|||
### 处理集成测试中的工作单元 |
|||
|
|||
ABP的[工作单元](Unit-Of-Work.md)系统控制应用程序中的数据库连接和事务管理. 它可以在你编写应用程序代码时无缝工作, 因此你可能没有意识到它. |
|||
|
|||
在ABP框架中, 所有数据库操作都必须在一个工作单元作用域内执行. 当你测试[应用服务](Application-Services.md)方法时, 工作单元的作用域将是应用服务方法的作用域. 如果你正在测试[仓储](Repositories.md)方法, 那么工作单元作用域将是你的仓储方法的作用域. |
|||
|
|||
在某些情况下, 你可能需要手动控制工作单元作用域. 可以考虑下面的测试方法: |
|||
|
|||
````csharp |
|||
public class IssueRepository_Tests : MyProjectDomainTestBase |
|||
{ |
|||
private readonly IRepository<Issue, Guid> _issueRepository; |
|||
|
|||
public IssueRepository_Tests() |
|||
{ |
|||
_issueRepository = GetRequiredService<IRepository<Issue, Guid>>(); |
|||
} |
|||
|
|||
public async Task Should_Query_By_Title() |
|||
{ |
|||
IQueryable<Issue> queryable = await _issueRepository.GetQueryableAsync(); |
|||
var issue = queryable.FirstOrDefaultAsync(i => i.Title == "My issue title"); |
|||
issue.ShouldNotBeNull(); |
|||
} |
|||
} |
|||
```` |
|||
|
|||
我们正在使用`_issueRepository.GetQueryableAsync`获取`IQueryable<Issue>` 对象. 然后, 我们使用`FirstOrDefaultAsync`方法按标题查询issue. 此时执行数据库查询, 你将会得到一个异常, 表明没有起作用的工作单元. |
|||
|
|||
要使该测试正常工作, 你应该手动启动工作单元作用域, 如下所示: |
|||
|
|||
````csharp |
|||
public class IssueRepository_Tests : MyProjectDomainTestBase |
|||
{ |
|||
private readonly IRepository<Issue, Guid> _issueRepository; |
|||
private readonly IUnitOfWorkManager _unitOfWorkManager; |
|||
|
|||
public IssueRepository_Tests() |
|||
{ |
|||
_issueRepository = GetRequiredService<IRepository<Issue, Guid>>(); |
|||
_unitOfWorkManager = GetRequiredService<IUnitOfWorkManager>(); |
|||
} |
|||
|
|||
public async Task Should_Query_By_Title() |
|||
{ |
|||
using (var uow = _unitOfWorkManager.Begin()) |
|||
{ |
|||
IQueryable<Issue> queryable = await _issueRepository.GetQueryableAsync(); |
|||
var issue = queryable.FirstOrDefaultAsync(i => i.Title == "My issue title"); |
|||
issue.ShouldNotBeNull(); |
|||
await uow.CompleteAsync(); |
|||
} |
|||
} |
|||
} |
|||
```` |
|||
|
|||
我们已经使用了`IUnitOfWorkManager`服务来创建一个工作单元作用域, 然后在该作用域内调用了`FirstOrDefaultAsync`方法, 所以不再有问题了. |
|||
|
|||
> 请注意, 我们测试了`FirstOrDefaultAsync`来演示工作单元的问题. 作为一个好的标准, 编写自己的代码. |
|||
|
|||
### 使用DbContext |
|||
|
|||
在某些情况下, 你可能希望使用Entity Framework的`DbContext`对象来执行测试方法中的数据库操作. 在这种情况下, 可以使用`IDbContextProvider<T>`服务在工作单元内获取`DbContext`实例. |
|||
|
|||
下面的示例展示了如何在测试方法中创建`DbContext`对象: |
|||
|
|||
````csharp |
|||
public class MyDbContext_Tests : MyProjectDomainTestBase |
|||
{ |
|||
private readonly IDbContextProvider<MyProjectDbContext> _dbContextProvider; |
|||
private readonly IUnitOfWorkManager _unitOfWorkManager; |
|||
|
|||
public IssueRepository_Tests() |
|||
{ |
|||
_dbContextProvider = GetRequiredService<IDbContextProvider<MyProjectDbContext>>(); |
|||
_unitOfWorkManager = GetRequiredService<IUnitOfWorkManager>(); |
|||
} |
|||
|
|||
public async Task Should_Query_By_Title() |
|||
{ |
|||
using (var uow = _unitOfWorkManager.Begin()) |
|||
{ |
|||
var dbContext = await _dbContextProvider.GetDbContextAsync(); |
|||
var issue = await dbContext.Issues.FirstOrDefaultAsync(i => i.Title == "My issue title"); |
|||
issue.ShouldNotBeNull(); |
|||
await uow.CompleteAsync(); |
|||
} |
|||
} |
|||
} |
|||
```` |
|||
|
|||
就像我们在*集成测试中处理工作单元*一节中所做的那样, 我们应该在起作用的工作单元内执行`DbContext`操作. |
|||
|
|||
对于[MongoDB](MongoDB.md), 你可以使用`IMongoDbContextProvider<T>`服务获取`DbContext`对象, 并在测试方法中直接使用MongoDB APIs. |
|||
|
|||
## 用户界面测试 |
|||
|
|||
一般来说, 有两种类型的UI测试: |
|||
|
|||
### 非可视化测试 |
|||
|
|||
此类测试完全取决于UI框架的选择: |
|||
|
|||
* 对于MVC / Razor页面UI, 通常向服务器发出请求, 获取HTML, 并测试返回的结果中是否存在一些预期的DOM元素. |
|||
* Angular有自己的基础设施和实践来测试组件、视图和服务. |
|||
|
|||
请参阅以下文档以了解非可视化UI测试: |
|||
|
|||
* [Testing in ASP.NET Core MVC / Razor Pages](UI/AspNetCore/Testing.md) |
|||
* [Testing in Angular](UI/Angular/Testing.md) |
|||
* [Testing in Blazor](UI/Blazor/Testing.md) |
|||
|
|||
### 可视化测试 |
|||
|
|||
与真实用户一样, 可视化测试用于与应用程序UI交互. 它全面测试应用程序, 包括页面和组件的外观. |
|||
|
|||
可视化UI测试超出了ABP框架的范围. 行业中有很多工具(比如[Selenium](https://www.selenium.dev/))可以用来测试应用程序的UI. |
|||
@ -0,0 +1,380 @@ |
|||
# Angular UI 单元测试 |
|||
|
|||
ABP Angular UI的测试与其他Angular应用程序一样. 所以, [这里的指南](https://angular.io/guide/testing)也适用于ABP. 也就是说, 我们想指出一些**特定于ABP Angular应用程序的单元测试内容**. |
|||
|
|||
## 设置 |
|||
|
|||
在Angular中, 单元测试默认使用[Karma](https://karma-runner.github.io/)和[Jasmine](https://jasmine.github.io). 虽然我们更喜欢Jest, 但我们选择不偏离这些默认设置, 因此**你下载的应用程序模板将预先配置Karma和Jasmine**. 你可以在根目录中的 _karma.conf.js_ 文件中找到Karma配置. 你什么都不用做. 添加一个spec文件并运行`npm test`即可. |
|||
|
|||
## 基础 |
|||
|
|||
简化版的spec文件如下所示: |
|||
|
|||
```js |
|||
import { CoreTestingModule } from "@abp/ng.core/testing"; |
|||
import { ThemeBasicTestingModule } from "@abp/ng.theme.basic/testing"; |
|||
import { ThemeSharedTestingModule } from "@abp/ng.theme.shared/testing"; |
|||
import { ComponentFixture, TestBed, waitForAsync } from "@angular/core/testing"; |
|||
import { NgxValidateCoreModule } from "@ngx-validate/core"; |
|||
import { MyComponent } from "./my.component"; |
|||
|
|||
describe("MyComponent", () => { |
|||
let fixture: ComponentFixture<MyComponent>; |
|||
|
|||
beforeEach( |
|||
waitForAsync(() => { |
|||
TestBed.configureTestingModule({ |
|||
declarations: [MyComponent], |
|||
imports: [ |
|||
CoreTestingModule.withConfig(), |
|||
ThemeSharedTestingModule.withConfig(), |
|||
ThemeBasicTestingModule.withConfig(), |
|||
NgxValidateCoreModule, |
|||
], |
|||
providers: [ |
|||
/* mock providers here */ |
|||
], |
|||
}).compileComponents(); |
|||
}) |
|||
); |
|||
|
|||
beforeEach(() => { |
|||
fixture = TestBed.createComponent(MyComponent); |
|||
fixture.detectChanges(); |
|||
}); |
|||
|
|||
it("should be initiated", () => { |
|||
expect(fixture.componentInstance).toBeTruthy(); |
|||
}); |
|||
}); |
|||
``` |
|||
|
|||
如果你看一下导入内容, 你会注意到我们已经准备了一些测试模块来取代内置的ABP模块. 这对于模拟某些特性是必要的, 否则这些特性会破坏你的测试. 请记住**使用测试模块**并**调用其`withConfig`静态方法**. |
|||
|
|||
## 提示 |
|||
|
|||
### Angular测试库 |
|||
|
|||
虽然你可以使用Angular TestBed测试代码, 但你可以找到一个好的替代品[Angular测试库](https://testing-library.com/docs/angular-testing-library/intro). |
|||
|
|||
上面的简单示例可以用Angular测试库编写, 如下所示: |
|||
|
|||
```js |
|||
import { CoreTestingModule } from "@abp/ng.core/testing"; |
|||
import { ThemeBasicTestingModule } from "@abp/ng.theme.basic/testing"; |
|||
import { ThemeSharedTestingModule } from "@abp/ng.theme.shared/testing"; |
|||
import { ComponentFixture } from "@angular/core/testing"; |
|||
import { NgxValidateCoreModule } from "@ngx-validate/core"; |
|||
import { render } from "@testing-library/angular"; |
|||
import { MyComponent } from "./my.component"; |
|||
|
|||
describe("MyComponent", () => { |
|||
let fixture: ComponentFixture<MyComponent>; |
|||
|
|||
beforeEach(async () => { |
|||
const result = await render(MyComponent, { |
|||
imports: [ |
|||
CoreTestingModule.withConfig(), |
|||
ThemeSharedTestingModule.withConfig(), |
|||
ThemeBasicTestingModule.withConfig(), |
|||
NgxValidateCoreModule, |
|||
], |
|||
providers: [ |
|||
/* mock providers here */ |
|||
], |
|||
}); |
|||
|
|||
fixture = result.fixture; |
|||
}); |
|||
|
|||
it("should be initiated", () => { |
|||
expect(fixture.componentInstance).toBeTruthy(); |
|||
}); |
|||
}); |
|||
``` |
|||
|
|||
正如你所见, 二者非常相似. 当我们使用查询和触发事件时, 真正的区别就显现出来了. |
|||
|
|||
```js |
|||
// other imports |
|||
import { getByLabelText, screen } from "@testing-library/angular"; |
|||
import userEvent from "@testing-library/user-event"; |
|||
|
|||
describe("MyComponent", () => { |
|||
beforeEach(/* removed for sake of brevity */); |
|||
|
|||
it("should display advanced filters", () => { |
|||
const filters = screen.getByTestId("author-filters"); |
|||
const nameInput = getByLabelText(filters, /name/i) as HTMLInputElement; |
|||
expect(nameInput.offsetWidth).toBe(0); |
|||
|
|||
const advancedFiltersBtn = screen.getByRole("link", { name: /advanced/i }); |
|||
userEvent.click(advancedFiltersBtn); |
|||
|
|||
expect(nameInput.offsetWidth).toBeGreaterThan(0); |
|||
|
|||
userEvent.type(nameInput, "fooo{backspace}"); |
|||
expect(nameInput.value).toBe("foo"); |
|||
}); |
|||
}); |
|||
``` |
|||
|
|||
**Angular测试库中的查询遵循可维护测试**, 用户事件库提供了与DOM的**类人交互**, 并且该库通常有**清晰的API**简化组件测试. 下面提供一些有用的链接: |
|||
|
|||
- [查询](https://testing-library.com/docs/dom-testing-library/api-queries) |
|||
- [用户事件](https://testing-library.com/docs/ecosystem-user-event) |
|||
- [范例](https://github.com/testing-library/angular-testing-library/tree/main/apps/example-app/src/app/examples) |
|||
|
|||
### 在每个Spec之后清除DOM |
|||
|
|||
需要记住的一点是, Karma在真实的浏览器实例中运行测试. 这意味着, 你将能够看到测试代码的结果, 但也会遇到与文档正文连接的组件的问题, 这些组件可能无法在每次测试后都清除, 即使你配置了Karma也一样无法清除. |
|||
|
|||
我们准备了一个简单的函数, 可以在每次测试后清除所有剩余的DOM元素. |
|||
|
|||
```js |
|||
// other imports |
|||
import { clearPage } from "@abp/ng.core/testing"; |
|||
|
|||
describe("MyComponent", () => { |
|||
let fixture: ComponentFixture<MyComponent>; |
|||
|
|||
afterEach(() => clearPage(fixture)); |
|||
|
|||
beforeEach(async () => { |
|||
const result = await render(MyComponent, { |
|||
/* removed for sake of brevity */ |
|||
}); |
|||
fixture = result.fixture; |
|||
}); |
|||
|
|||
// specs here |
|||
}); |
|||
``` |
|||
|
|||
请确保你使用它, 否则Karma将无法删除对话框, 并且你将有多个模态对话框、确认框等的副本. |
|||
|
|||
### 等待 |
|||
|
|||
一些组件, 特别是在检测周期之外工作的模态对话框. 换句话说, 你无法在打开这些组件后立即访问这些组件插入的DOM元素. 同样, 插入的元素在关闭时也不会立即销毁. |
|||
|
|||
为此, 我们准备了一个`wait`函数. |
|||
|
|||
```js |
|||
// other imports |
|||
import { wait } from "@abp/ng.core/testing"; |
|||
|
|||
describe("MyComponent", () => { |
|||
beforeEach(/* removed for sake of brevity */); |
|||
|
|||
it("should open a modal", async () => { |
|||
const openModalBtn = screen.getByRole("button", { name: "Open Modal" }); |
|||
userEvent.click(openModalBtn); |
|||
|
|||
await wait(fixture); |
|||
|
|||
const modal = screen.getByRole("dialog"); |
|||
|
|||
expect(modal).toBeTruthy(); |
|||
|
|||
/* wait again after closing the modal */ |
|||
}); |
|||
}); |
|||
``` |
|||
|
|||
`wait`函数接受第二个参数, 即超时(默认值为`0`). 但是尽量不要使用它. 使用大于`0`的超时通常表明某些不正确事情发生了. |
|||
|
|||
## 测试示例 |
|||
|
|||
下面是一个测试示例. 它并没有涵盖所有内容, 但却能够对测试有一个更好的了解. |
|||
|
|||
```js |
|||
import { clearPage, CoreTestingModule, wait } from "@abp/ng.core/testing"; |
|||
import { ThemeBasicTestingModule } from "@abp/ng.theme.basic/testing"; |
|||
import { ThemeSharedTestingModule } from "@abp/ng.theme.shared/testing"; |
|||
import { ComponentFixture } from "@angular/core/testing"; |
|||
import { |
|||
NgbCollapseModule, |
|||
NgbDatepickerModule, |
|||
NgbDropdownModule, |
|||
} from "@ng-bootstrap/ng-bootstrap"; |
|||
import { NgxValidateCoreModule } from "@ngx-validate/core"; |
|||
import { CountryService } from "@proxy/countries"; |
|||
import { |
|||
findByText, |
|||
getByLabelText, |
|||
getByRole, |
|||
getByText, |
|||
queryByRole, |
|||
render, |
|||
screen, |
|||
} from "@testing-library/angular"; |
|||
import userEvent from "@testing-library/user-event"; |
|||
import { BehaviorSubject, of } from "rxjs"; |
|||
import { CountryComponent } from "./country.component"; |
|||
|
|||
const list$ = new BehaviorSubject({ |
|||
items: [{ id: "ID_US", name: "United States of America" }], |
|||
totalCount: 1, |
|||
}); |
|||
|
|||
describe("Country", () => { |
|||
let fixture: ComponentFixture<CountryComponent>; |
|||
|
|||
afterEach(() => clearPage(fixture)); |
|||
|
|||
beforeEach(async () => { |
|||
const result = await render(CountryComponent, { |
|||
imports: [ |
|||
CoreTestingModule.withConfig(), |
|||
ThemeSharedTestingModule.withConfig(), |
|||
ThemeBasicTestingModule.withConfig(), |
|||
NgxValidateCoreModule, |
|||
NgbCollapseModule, |
|||
NgbDatepickerModule, |
|||
NgbDropdownModule, |
|||
], |
|||
providers: [ |
|||
{ |
|||
provide: CountryService, |
|||
useValue: { |
|||
getList: () => list$, |
|||
}, |
|||
}, |
|||
], |
|||
}); |
|||
|
|||
fixture = result.fixture; |
|||
}); |
|||
|
|||
it("should display advanced filters", () => { |
|||
const filters = screen.getByTestId("country-filters"); |
|||
const nameInput = getByLabelText(filters, /name/i) as HTMLInputElement; |
|||
expect(nameInput.offsetWidth).toBe(0); |
|||
|
|||
const advancedFiltersBtn = screen.getByRole("link", { name: /advanced/i }); |
|||
userEvent.click(advancedFiltersBtn); |
|||
|
|||
expect(nameInput.offsetWidth).toBeGreaterThan(0); |
|||
|
|||
userEvent.type(nameInput, "fooo{backspace}"); |
|||
expect(nameInput.value).toBe("foo"); |
|||
|
|||
userEvent.click(advancedFiltersBtn); |
|||
expect(nameInput.offsetWidth).toBe(0); |
|||
}); |
|||
|
|||
it("should have a heading", () => { |
|||
const heading = screen.getByRole("heading", { name: "Countries" }); |
|||
expect(heading).toBeTruthy(); |
|||
}); |
|||
|
|||
it("should render list in table", async () => { |
|||
const table = await screen.findByTestId("country-table"); |
|||
|
|||
const name = getByText(table, "United States of America"); |
|||
expect(name).toBeTruthy(); |
|||
}); |
|||
|
|||
it("should display edit modal", async () => { |
|||
const actionsBtn = screen.queryByRole("button", { name: /actions/i }); |
|||
userEvent.click(actionsBtn); |
|||
|
|||
const editBtn = screen.getByRole("button", { name: /edit/i }); |
|||
userEvent.click(editBtn); |
|||
|
|||
await wait(fixture); |
|||
|
|||
const modal = screen.getByRole("dialog"); |
|||
const modalHeading = queryByRole(modal, "heading", { name: /edit/i }); |
|||
expect(modalHeading).toBeTruthy(); |
|||
|
|||
const closeBtn = getByText(modal, "×"); |
|||
userEvent.click(closeBtn); |
|||
|
|||
await wait(fixture); |
|||
|
|||
expect(screen.queryByRole("dialog")).toBeFalsy(); |
|||
}); |
|||
|
|||
it("should display create modal", async () => { |
|||
const newBtn = screen.getByRole("button", { name: /new/i }); |
|||
userEvent.click(newBtn); |
|||
|
|||
await wait(fixture); |
|||
|
|||
const modal = screen.getByRole("dialog"); |
|||
const modalHeading = queryByRole(modal, "heading", { name: /new/i }); |
|||
|
|||
expect(modalHeading).toBeTruthy(); |
|||
}); |
|||
|
|||
it("should validate required name field", async () => { |
|||
const newBtn = screen.getByRole("button", { name: /new/i }); |
|||
userEvent.click(newBtn); |
|||
|
|||
await wait(fixture); |
|||
|
|||
const modal = screen.getByRole("dialog"); |
|||
const nameInput = getByRole(modal, "textbox", { |
|||
name: /^name/i, |
|||
}) as HTMLInputElement; |
|||
|
|||
userEvent.type(nameInput, "x"); |
|||
userEvent.type(nameInput, "{backspace}"); |
|||
|
|||
const nameError = await findByText(modal, /required/i); |
|||
expect(nameError).toBeTruthy(); |
|||
}); |
|||
|
|||
it("should delete a country", () => { |
|||
const getSpy = spyOn(fixture.componentInstance.list, "get"); |
|||
const deleteSpy = jasmine.createSpy().and.returnValue(of(null)); |
|||
fixture.componentInstance.service.delete = deleteSpy; |
|||
|
|||
const actionsBtn = screen.queryByRole("button", { name: /actions/i }); |
|||
userEvent.click(actionsBtn); |
|||
|
|||
const deleteBtn = screen.getByRole("button", { name: /delete/i }); |
|||
userEvent.click(deleteBtn); |
|||
|
|||
const confirmText = screen.getByText("AreYouSure"); |
|||
expect(confirmText).toBeTruthy(); |
|||
|
|||
const confirmBtn = screen.getByRole("button", { name: "Yes" }); |
|||
userEvent.click(confirmBtn); |
|||
|
|||
expect(deleteSpy).toHaveBeenCalledWith(list$.value.items[0].id); |
|||
expect(getSpy).toHaveBeenCalledTimes(1); |
|||
}); |
|||
}); |
|||
``` |
|||
|
|||
## CI配置 |
|||
|
|||
你的CI环境需要不同的配置. 要为单元测试设置新的配置, 请在测试项目中找到 _angular.json_ 文件, 或者如下所示添加一个: |
|||
|
|||
```json |
|||
// angular.json |
|||
|
|||
"test": { |
|||
"builder": "@angular-devkit/build-angular:karma", |
|||
"options": { /* several options here */ }, |
|||
"configurations": { |
|||
"production": { |
|||
"karmaConfig": "karma.conf.prod.js" |
|||
} |
|||
} |
|||
} |
|||
``` |
|||
|
|||
现在你可以复制 _karma.conf.js_ 作为 _karma.conf.prod.js_ 并在其中使用你喜欢的任何配置. 请查看[Karma配置文档](http://karma-runner.github.io/5.2/config/configuration-file.html)配置选项. |
|||
|
|||
最后, 不要忘记使用以下命令运行CI测试: |
|||
|
|||
```sh |
|||
npm test -- --prod |
|||
``` |
|||
|
|||
## 另请参阅 |
|||
|
|||
- [ABP Community Video - Unit Testing with the Angular UI](https://community.abp.io/articles/unit-testing-with-the-angular-ui-p4l550q3) |
|||
@ -0,0 +1,220 @@ |
|||
# ASP.NET Core MVC / Razor Pages: 测试 |
|||
|
|||
> 你可以参考[ASP.NET Core集成测试文档](https://docs.microsoft.com/en-us/aspnet/core/test/integration-tests)了解ASP.NET Core集成测试的详细内容. 本文档解释了ABP框架提供的附加测试基础设施. |
|||
|
|||
## 应用程序启动模板 |
|||
|
|||
应用程序启动模板的`.Web`项目其中包含应用程序的UI视图/页面/组件, 并提供`.Web.Tests`项目来测试这些内容. |
|||
|
|||
 |
|||
|
|||
## 测试Razor页面 |
|||
|
|||
假设你已经创建了一个名为`Issues.cshtml`的Razor页面, 包含以下内容; |
|||
|
|||
**Issues.cshtml.cs** |
|||
|
|||
````csharp |
|||
using System.Collections.Generic; |
|||
using System.Threading.Tasks; |
|||
using Microsoft.AspNetCore.Mvc.RazorPages; |
|||
using MyProject.Issues; |
|||
|
|||
namespace MyProject.Web.Pages |
|||
{ |
|||
public class IssuesModel : PageModel |
|||
{ |
|||
public List<IssueDto> Issues { get; set; } |
|||
|
|||
private readonly IIssueAppService _issueAppService; |
|||
|
|||
public IssuesModel(IIssueAppService issueAppService) |
|||
{ |
|||
_issueAppService = issueAppService; |
|||
} |
|||
|
|||
public async Task OnGetAsync() |
|||
{ |
|||
Issues = await _issueAppService.GetListAsync(); |
|||
} |
|||
} |
|||
} |
|||
```` |
|||
|
|||
**Issues.cshtml** |
|||
|
|||
````html |
|||
@page |
|||
@model MyProject.Web.Pages.IssuesModel |
|||
<h2>Issue List</h2> |
|||
<table id="IssueTable" class="table"> |
|||
<thead> |
|||
<tr> |
|||
<th>Issue</th> |
|||
<th>Closed?</th> |
|||
</tr> |
|||
</thead> |
|||
<tbody> |
|||
@foreach (var issue in Model.Issues) |
|||
{ |
|||
<tr> |
|||
<td>@issue.Title</td> |
|||
<td> |
|||
@if (issue.IsClosed) |
|||
{ |
|||
<span>Closed</span> |
|||
} |
|||
else |
|||
{ |
|||
<span>Open</span> |
|||
} |
|||
</td> |
|||
</tr> |
|||
} |
|||
</tbody> |
|||
</table> |
|||
```` |
|||
|
|||
本页仅创建一个包含issue的表格: |
|||
|
|||
 |
|||
|
|||
你可以在`.Web.Tests`项目中编写一个测试类如下所示: |
|||
|
|||
````csharp |
|||
using System.Threading.Tasks; |
|||
using HtmlAgilityPack; |
|||
using Shouldly; |
|||
using Xunit; |
|||
|
|||
namespace MyProject.Pages |
|||
{ |
|||
public class Issues_Tests : MyProjectWebTestBase |
|||
{ |
|||
[Fact] |
|||
public async Task Should_Get_Table_Of_Issues() |
|||
{ |
|||
// Act |
|||
|
|||
var response = await GetResponseAsStringAsync("/Issues"); |
|||
|
|||
//Assert |
|||
|
|||
var htmlDocument = new HtmlDocument(); |
|||
htmlDocument.LoadHtml(response); |
|||
|
|||
var tableElement = htmlDocument.GetElementbyId("IssueTable"); |
|||
tableElement.ShouldNotBeNull(); |
|||
|
|||
var trNodes = tableElement.SelectNodes("//tbody/tr"); |
|||
trNodes.Count.ShouldBeGreaterThan(0); |
|||
} |
|||
} |
|||
} |
|||
```` |
|||
|
|||
`GetResponseAsStringAsync`是一个快捷方法, 它来自执行HTTP GET请求的基类, 检查生成的HTTP状态是否为`200`, 并将响应作为`string`返回. |
|||
|
|||
> 你可以使用`Client`对象(类型为`HttpClient`)对服务器执行任何类型的请求, 并读取响应.`GetResponseAsStringAsync`只是一种快捷方法. |
|||
|
|||
本例使用[HtmlAgilityPack](https://html-agility-pack.net/)库来解析传入的HTML并测试它是否包含issue表格. |
|||
|
|||
> 本例假设的数据库中存在一些初始issue. 请参阅[测试文档](../../Testing.md)的*种子数据*部分, 了解如何设置种子数据, 以便可以假定数据库中有一些可用的初始数据. |
|||
|
|||
## 控制器测试 |
|||
|
|||
测试控制器也不例外. 只需使用正确的URL向服务器执行请求, 获取响应并做出断言. |
|||
|
|||
### 查看结果 |
|||
|
|||
如果控制器返回一个视图, 你可以使用类似的代码来测试返回的HTML. 参见上面的Razor页面示例. |
|||
|
|||
### 对象结果 |
|||
|
|||
如果控制器返回对象结果, 则可以使用`GetResponseAsObjectAsync`方法. |
|||
|
|||
假设你有一个如下定义的控制器: |
|||
|
|||
````csharp |
|||
using System.Collections.Generic; |
|||
using System.Threading.Tasks; |
|||
using Microsoft.AspNetCore.Mvc; |
|||
using MyProject.Issues; |
|||
using Volo.Abp.AspNetCore.Mvc; |
|||
|
|||
namespace MyProject.Web.Controllers |
|||
{ |
|||
[Route("api/issues")] |
|||
public class IssueController : AbpController |
|||
{ |
|||
private readonly IIssueAppService _issueAppService; |
|||
|
|||
public IssueController(IIssueAppService issueAppService) |
|||
{ |
|||
_issueAppService = issueAppService; |
|||
} |
|||
|
|||
[HttpGet] |
|||
public async Task<List<IssueDto>> GetAsync() |
|||
{ |
|||
return await _issueAppService.GetListAsync(); |
|||
} |
|||
} |
|||
} |
|||
```` |
|||
|
|||
你可以编写测试代码来调用API并获得结果: |
|||
|
|||
````csharp |
|||
using System.Collections.Generic; |
|||
using System.Threading.Tasks; |
|||
using MyProject.Issues; |
|||
using Shouldly; |
|||
using Xunit; |
|||
|
|||
namespace MyProject.Pages |
|||
{ |
|||
public class Issues_Tests : MyProjectWebTestBase |
|||
{ |
|||
[Fact] |
|||
public async Task Should_Get_Issues_From_Api() |
|||
{ |
|||
var issues = await GetResponseAsObjectAsync<List<IssueDto>>("/api/issues"); |
|||
|
|||
issues.ShouldNotBeNull(); |
|||
issues.Count.ShouldBeGreaterThan(0); |
|||
} |
|||
} |
|||
} |
|||
```` |
|||
|
|||
## 测试JavaScript代码 |
|||
|
|||
ABP框架不提供任何基础设施来测试JavaScript代码. 你可以使用任何测试框架和工具来测试JavaScript代码. |
|||
|
|||
## 测试基础设施 |
|||
|
|||
[Volo.Abp.AspNetCore.TestBase](https://www.nuget.org/packages/Volo.Abp.AspNetCore.TestBase) 提供了集成到ABP框架和ASP.NET Core的测试基础设施. |
|||
|
|||
> Volo.Abp.AspNetCore.TestBase 已经安装在 `.Web.Tests` 项目中. |
|||
|
|||
此包提供的`AbpAspNetCoreIntegratedTestBase`作为派生测试类的基类. 上面使用的`MyProjectWebTestBase`继承自`AbpAspNetCoreIntegratedTestBase`, 因此我们间接继承了`AbpAspNetCoreIntegratedTestBase`. |
|||
|
|||
### 基本属性 |
|||
|
|||
`AbpAspNetCoreIntegratedTestBase` 提供了测试中使用的以下基本属性: |
|||
|
|||
* `Server`: 在测试中托管web应用程序的`TestServer`实例. |
|||
* `Client`: 为执行对测试服务器的请求配置`HttpClient`实例. |
|||
* `ServiceProvider`: 可以在你需要时处理服务提供服务. |
|||
|
|||
### 基本方法 |
|||
|
|||
`AbpAspNetCoreIntegratedTestBase` 提供了以下方法, 如果需要自定义测试服务器, 可以重写这些方法: |
|||
|
|||
* `ConfigureServices` 仅为派生测试类注册/替换服务时可以重写使用. |
|||
* `CreateHostBuilder` 可用于自定义生成 `IHostBuilder`. |
|||
|
|||
另请参阅 |
|||
|
|||
* [总览/服务器端测试](../../Testing.md) |
|||
|
After Width: | Height: | Size: 40 KiB |
|
After Width: | Height: | Size: 30 KiB |
@ -0,0 +1,28 @@ |
|||
using System.Linq; |
|||
|
|||
namespace Volo.Abp.Cli.ProjectBuilding.Building.Steps; |
|||
|
|||
public class MoveFileStep : ProjectBuildPipelineStep |
|||
{ |
|||
private readonly string _filePath; |
|||
private readonly string _newPath; |
|||
|
|||
public MoveFileStep(string filePath, string newPath) |
|||
{ |
|||
_filePath = filePath; |
|||
_newPath = newPath; |
|||
} |
|||
|
|||
public override void Execute(ProjectBuildContext context) |
|||
{ |
|||
var fileToMove = context.Files.Find(x => x.Name == _filePath); |
|||
var newFileExist = context.Files.Any(x => x.Name == _newPath); |
|||
|
|||
if (fileToMove == null || newFileExist) |
|||
{ |
|||
return; |
|||
} |
|||
|
|||
fileToMove.SetName(_newPath); |
|||
} |
|||
} |
|||
@ -1,8 +1,8 @@ |
|||
using System.Threading.Tasks; |
|||
|
|||
// ReSharper disable once CheckNamespace (Keeping for backward compability)
|
|||
namespace Volo.Abp.EventBus; |
|||
|
|||
//TODO: Move to the right namespace in v3.0
|
|||
public interface ILocalEventHandler<in TEvent> : IEventHandler |
|||
{ |
|||
/// <summary>
|
|||
@ -0,0 +1,18 @@ |
|||
using Confluent.Kafka; |
|||
|
|||
namespace Volo.Abp.EventBus.Kafka; |
|||
|
|||
public static class MessageExtensions |
|||
{ |
|||
public static string GetMessageId<TKey, TValue>(this Message<TKey, TValue> message) |
|||
{ |
|||
string messageId = null; |
|||
|
|||
if (message.Headers.TryGetLastBytes("messageId", out var messageIdBytes)) |
|||
{ |
|||
messageId = System.Text.Encoding.UTF8.GetString(messageIdBytes); |
|||
} |
|||
|
|||
return messageId; |
|||
} |
|||
} |
|||
@ -0,0 +1,3 @@ |
|||
<Weavers xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="FodyWeavers.xsd"> |
|||
<ConfigureAwait ContinueOnCapturedContext="false"/> |
|||
</Weavers> |
|||
@ -0,0 +1,30 @@ |
|||
<?xml version="1.0" encoding="utf-8"?> |
|||
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> |
|||
<!-- This file was generated by Fody. Manual changes to this file will be lost when your project is rebuilt. --> |
|||
<xs:element name="Weavers"> |
|||
<xs:complexType> |
|||
<xs:all> |
|||
<xs:element name="ConfigureAwait" minOccurs="0" maxOccurs="1"> |
|||
<xs:complexType> |
|||
<xs:attribute name="ContinueOnCapturedContext" type="xs:boolean" /> |
|||
</xs:complexType> |
|||
</xs:element> |
|||
</xs:all> |
|||
<xs:attribute name="VerifyAssembly" type="xs:boolean"> |
|||
<xs:annotation> |
|||
<xs:documentation>'true' to run assembly verification (PEVerify) on the target assembly after all weavers have been executed.</xs:documentation> |
|||
</xs:annotation> |
|||
</xs:attribute> |
|||
<xs:attribute name="VerifyIgnoreCodes" type="xs:string"> |
|||
<xs:annotation> |
|||
<xs:documentation>A comma-separated list of error codes that can be safely ignored in assembly verification.</xs:documentation> |
|||
</xs:annotation> |
|||
</xs:attribute> |
|||
<xs:attribute name="GenerateXsd" type="xs:boolean"> |
|||
<xs:annotation> |
|||
<xs:documentation>'false' to turn off automatic generation of the XML Schema file.</xs:documentation> |
|||
</xs:annotation> |
|||
</xs:attribute> |
|||
</xs:complexType> |
|||
</xs:element> |
|||
</xs:schema> |
|||
@ -0,0 +1,15 @@ |
|||
<Project Sdk="Microsoft.NET.Sdk"> |
|||
|
|||
<Import Project="..\..\..\configureawait.props" /> |
|||
<Import Project="..\..\..\common.props" /> |
|||
|
|||
<PropertyGroup> |
|||
<TargetFramework>netstandard2.0</TargetFramework> |
|||
<RootNamespace /> |
|||
</PropertyGroup> |
|||
|
|||
<ItemGroup> |
|||
<ProjectReference Include="..\Volo.Abp.Core\Volo.Abp.Core.csproj" /> |
|||
</ItemGroup> |
|||
|
|||
</Project> |
|||
@ -0,0 +1,7 @@ |
|||
using Volo.Abp.Modularity; |
|||
|
|||
namespace Volo.Abp.Gdpr; |
|||
|
|||
public class AbpGdprAbstractionsModule : AbpModule |
|||
{ |
|||
} |
|||
@ -0,0 +1,10 @@ |
|||
using System; |
|||
using System.Collections.Generic; |
|||
|
|||
namespace Volo.Abp.Gdpr; |
|||
|
|||
[Serializable] |
|||
public class GdprDataInfo : Dictionary<string, string> |
|||
{ |
|||
|
|||
} |
|||
@ -0,0 +1,9 @@ |
|||
using System; |
|||
|
|||
namespace Volo.Abp.Gdpr; |
|||
|
|||
[Serializable] |
|||
public class GdprUserDataDeletionRequestedEto |
|||
{ |
|||
public Guid UserId { get; set; } |
|||
} |
|||
@ -0,0 +1,13 @@ |
|||
using System; |
|||
|
|||
namespace Volo.Abp.Gdpr; |
|||
|
|||
[Serializable] |
|||
public class GdprUserDataPreparedEto |
|||
{ |
|||
public Guid RequestId { get; set; } |
|||
|
|||
public string Provider { get; set; } |
|||
|
|||
public GdprDataInfo Data { get; set; } |
|||
} |
|||
@ -0,0 +1,8 @@ |
|||
using System; |
|||
|
|||
namespace Volo.Abp.Gdpr; |
|||
|
|||
public class GdprUserDataProviderContext |
|||
{ |
|||
public Guid UserId { get; set; } |
|||
} |
|||
@ -0,0 +1,11 @@ |
|||
using System; |
|||
|
|||
namespace Volo.Abp.Gdpr; |
|||
|
|||
[Serializable] |
|||
public class GdprUserDataRequestedEto |
|||
{ |
|||
public Guid UserId { get; set; } |
|||
|
|||
public Guid RequestId { get; set; } |
|||
} |
|||
Some files were not shown because too many files changed in this diff
Loading…
Reference in new issue