ABP Get Started

现根据https://docs.abp.io/en/abp/latest/Getting-Started  配置好开发环境

1. Setup your development environment
2. Creating a new solution
3. Running the solution

Create a New Project

We will use the ABP CLI to create a new ABP project.

Alternatively, you can create and download projects from the ABP Framework website by easily selecting all options from the page.

Use the new command of the ABP CLI to create a new project:

abp new Acme.BookStore --tiered

You can use different level of namespaces; e.g. BookStore, Acme.BookStore or Acme.Retail.BookStore.

• --tiered argument is used to create N-tiered solution where authentication server, UI and API layers are physically separated.

ABP CLI document covers all of the available commands and options.

 

不带tiered参数，执行完成之后，https://www.abp.io/project-created-success?ui=Mvc&db=EntityFrameworkCore&tiered=no   

 

The Solution Structure

The solution has a layered structure (based on the Domain Driven Design) and contains unit & integration test projects.

See the application template document to understand the solution structure in details.

 

https://docs.abp.io/en/abp/latest/Startup-Templates/Application#solution-structure

Solution Structure

Based on the options you've specified, you will get a slightly different solution structure.

Default Structure

If you don't specify any additional options, you will have a solution as shown below:

Projects are organized in src and test folders. src folder contains the actual application which is layered based on DDD principles as mentioned before.

The diagram below shows the layers & project dependencies of the application:

Each section below will explain the related project & its dependencies.

.Domain.Shared Project

This project contains constants, enums and other objects these are actually a part of the domain layer, but needed to be used by all layers/projects in the solution.

A BookType enum and a BookConsts class (which may have some constant fields for the Book entity, like MaxNameLength) are good candidates for this project.

• This project has no dependency on other projects in the solution. All other projects depend on this one directly or indirectly.

.Domain Project

This is the domain layer of the solution. It mainly contains entities, aggregate roots, domain services, value objects, repository interfaces and other domain objects.

A Book entity, a BookManager domain service and an IBookRepository interface are good candidates for this project.

• Depends on the .Domain.Shared because it uses constants, enums and other objects defined in that project.

.Application.Contracts Project

This project mainly contains application service interfaces and Data Transfer Objects (DTO) of the application layer. It exists to separate the interface & implementation of the application layer. In this way, the interface project can be shared to the clients as a contract package.

An IBookAppService interface and a BookCreationDto class are good candidates for this project.

• Depends on the .Domain.Shared because it may use constants, enums and other shared objects of this project in the application service interfaces and DTOs.

.Application Project

This project contains the application service implementations of the interfaces defined in the .Application.Contracts project.

A BookAppService class is a good candidate for this project.

• Depends on the .Application.Contracts project to be able to implement the interfaces and use the DTOs.
• Depends on the .Domain project to be able to use domain objects (entities, repository interfaces... etc.) to perform the application logic.

.EntityFrameworkCore Project

This is the integration project for the EF Core. It defines the DbContext and implements repository interfaces defined in the .Domain project.

• Depends on the .Domain project to be able to reference to entities and repository interfaces.

This project is available only if you are using EF Core as the database provider. If you select another database provider, its name will be different.

.DbMigrator Project

This is a console application that simplifies the execution of database migrations on development and production environments. When you run this application, it:

• Creates the database if necessary.
• Applies the pending database migrations.
• Seeds initial data if needed.

This project has its own appsettings.json file. So, if you want to change the database connection string, remember to change this file too.

Especially, seeding initial data is important at this point. ABP has a modular data seed infrastructure. See its documentation for more about the data seeding.

While creating database & applying migrations seem only necessary for relational databases, this project comes even if you choose a NoSQL database provider (like MongoDB). In that case, it still seeds the initial data which is necessary for the application.

• Depends on the .EntityFrameworkCore project (for EF Core) since it needs to access to the migrations.
• Depends on the .Application.Contracts project to be able to access permission definitions, because the initial data seeder grants all permissions to the admin role by default.

.HttpApi Project

This project is used to define your API Controllers.

Most of the time you don't need to manually define API Controllers since ABP's Auto API Controllers feature creates them automagically based on your application layer. However, in case of you need to write API controllers, this is the best place to do it.

• Depends on the .Application.Contracts project to be able to inject the application service interfaces.

.HttpApi.Client Project

This is a project that defines C# client proxies to use the HTTP APIs of the solution. You can share this library to 3rd-party clients, so they can easily consume your HTTP APIs in their Dotnet applications (For other types of applications, they can still use your APIs, either manually or using a tool in their own platform)

Most of the time you don't need to manually create C# client proxies, thanks to ABP's Dynamic C# API Clients feature.

.HttpApi.Client.ConsoleTestApp project is a console application created to demonstrate the usage of the client proxies.

• Depends on the .Application.Contracts project to be able to share the same application service interfaces and DTOs with the remote service.

You can delete this project & dependencies if you don't need to create C# client proxies for your APIs.

.Web Project

This project contains the User Interface (UI) of the application if you are using ASP.NET Core MVC UI. It contains Razor pages, JavaScript files, CSS files, images and so on...

This project contains the main appsettings.json file that contains the connection string and other configurations of the application.

• Depends on the .HttpApi project since the UI layer needs to use APIs and the application service interfaces of the solution.

If you check the source code of the .Web.csproj file, you will see the references to the .Application and the .EntityFrameworkCore projects.

These references are actually not needed while coding your UI layer, because the UI layer normally doesn't depend on the EF Core or the Application layer's implementation. These startup templates are ready for tiered deployment, where the API layer is hosted on a separate server than the UI layer.

However, if you don't choose the --tiered option, these references will be in the .Web project to be able to host the Web, API and application layers in a single application endpoint.

This gives you the ability to use domain entities & repositories in your presentation layer. However, this is considered as a bad practice according to DDD.

Test Projects

The solution has multiple test projects, one for each layer:

• .Domain.Tests is used to test the domain layer.
• .Application.Tests is used to test the application layer.
• .EntityFrameworkCore.Tests is used to test EF Core configuration and custom repositories.
• .Web.Tests is used to test the UI (if you are using ASP.NET Core MVC UI).
• .TestBase is a base (shared) project for all tests.

In addition, .HttpApi.Client.ConsoleTestApp is a console application (not an automated test project) which demonstrate the usage of HTTP APIs from a .NET application.

Test projects are prepared for integration testing;

• It is fully integrated into the ABP framework and all services in your application.
• It uses SQLite in-memory database for EF Core. For MongoDB, it uses the Mongo2Go library.
• Authorization is disabled, so any application service can be easily used in tests.

You can still create unit tests for your classes which will be harder to write (because you will need to prepare mock/fake objects), but faster to run (because it only tests a single class and skips all the initialization processes).

How to Run?

Set .Web as the startup project and run the application. The default username is admin and the password is 1q2w3E*.

See Getting Started With the ASP.NET Core MVC Template for more information.

项目本身是这个https://localhost:44389/Identity/Users

访问swagger页面，可以看到一堆和login， account，permission相关的api。

上面这些api是因为生成的项目自动引用了nuget中的这些Application。

 

 

Create the Database

Connection String

Check the connection string in the appsettings.json file under the .AuthServer and .HttpApi.Host projects.

"ConnectionStrings": {
  "Default": "Server=(LocalDb)\MSSQLLocalDB;Database=BookStore;Trusted_Connection=True"
}

JSON

Copy

About the Connection Strings and Database Management Systems

The solution is configured to use Entity Framework Core with MS SQL Server by default. However, if you've selected another DBMS using the -dbms parameter on the ABP CLI new command (like -dbms MySQL), the connection string might be different for you.

EF Core supports various database providers and you can use any supported DBMS. See the Entity Framework integration document to learn how to switch to another DBMS if you need later.

Database Migrations

The solution uses the Entity Framework Core Code First Migrations. It comes with a .DbMigrator console application which applies the migrations and also seeds the 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.

The Initial Migration

.DbMigrator application automatically creates the Initial migration on first run.

If you are using Visual Studio, you can skip to the Running the DbMigrator section. However, other IDEs (e.g. Rider) may have problems for the first run since it adds the initial migration and compiles the project. In this case, open a command line terminal in the folder of the .DbMigrator project and run the following command:

dotnet run

For the next time, you can just run it in your IDE as you normally do.

 

Initial seed data creates the admin user in the database (with the password is 1q2w3E*) which is then used to login to the application. So, you need to use .DbMigrator at least once for a new database.

 

Run the Application

Before starting the application, run abp install-libs command in your Web directory to restore the client-side libraries. This will populate the libs folder.

Tiered solutions use Redis as the distributed cache. Ensure that it is installed and running in your local computer. If you are using a remote Redis Server, set the configuration in the appsettings.json files of the projects below.

1. Ensure that the .AuthServer project is the startup project. Run this application that will open a login page in your browser.

Use Ctrl+F5 in Visual Studio (instead of F5) to run the application without debugging. If you don't have a debug purpose, this will be faster.

You can login, but you cannot enter to the main application here. This is just the authentication server.

2. Ensure that the .HttpApi.Host project is the startup project and run the application which will open a Swagger UI in your browser.

 

作者:Chuck Lu    GitHub