@ -30,11 +30,7 @@ abp new Acme.IssueManagement -t mvc-module --no-ui
## 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 option, you will have a solution like shown below:
Based on the options you've specified, you will get a slightly different solution structure. If you don't specify any option, you will have a solution like shown below:
@ -50,7 +46,7 @@ The diagram below shows the layers & project dependencies of the module:
Each section below will explain the related project & its dependencies.
#### .Domain.Shared Project
### .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.
@ -58,7 +54,7 @@ An `IssueType` enum and an `IssueConts` class (which may have some constant fiel
- This project has no dependency to other projects in the solution. All other projects depend on this directly or indirectly.
#### .Domain Project
### .Domain Project
This is the domain layer of the solution. It mainly contains [entities, aggregate roots](../Entities.md), [domain services](../Domain-Services.md), [value types](../Value-Types.md), [repository interfaces](../Repositories.md) and other domain objects.
@ -66,7 +62,7 @@ An `Issue` entity, an `IssueManager` domain service and an `IIssueRepository` in
- Depends on the `.Domain.Shared` because it uses constants, enums and other objects defined in that project.
#### .Application.Contracts Project
### .Application.Contracts Project
This project mainly contains [application service](../Application-Services.md) **interfaces** and [Data Transfer Objects](../Data-Transfer-Objects.md) (DTO) of the application layer. It does exists to separate interface & implementation of the application layer. In this way, the interface project can be shared to the clients as a contract package.
@ -74,7 +70,7 @@ An `IIssueAppService` interface and an `IssueCreationDto` class are good candida
- 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
### .Application Project
This project contains the [application service](../Application-Services.md) **implementations** of the interfaces defined in the `.Application.Contracts` project.
@ -83,10 +79,82 @@ An `IssueAppService` 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
### .EntityFrameworkCore Project
This is the integration project for the EF Core. It defines the `DbContext` and implements repository interfaces defined in the `.Domain` project.
This is the integration project for 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.
> You can delete this project if you don't want to support EF Core for your module.
> You can delete this project if you don't want to support EF Core for your module.
### .MongoDB Project
This is the integration project for MongoDB.
- Depends on the `.Domain` project to be able to reference to entities and repository interfaces.
> You can delete this project if you don't want to support MongoDB for your module.
### 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.
- `.MongoDB.Tests` is used to test EF Core configuration and custom repositories.
- `.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 Dotnet application.
Test projects are prepared for integration testing;
- It is fully integrated to ABP framework and all services in your application.
- It uses SQLite in-memory database for EF Core. For MongoDB, it uses the [Mongo2Go](https://github.com/Mongo2Go/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 initialization process).
> Domain & Application tests are using EF Core. If you remove EF Core integration or you want to use MongoDB for testing these layers, you should manually change project references & module dependencies.
### Host Projects
The solution has a few host applications to run your module on development. Host applications are used to run your module in a fully configured application. It is useful on development. Host applications includes some other modules in addition to the module being developed:
*
Host applications support two types of scenarios.
#### Single (Unified) Application Scenario
If your module has a UI, then `.Web.Unified` application is used to host the UI and API on a single point. It has its own `appsettings.json` file (that includes the database connection string) and EF Core database migrations.
For the `.Web.Unified` application, there is a single database, named `YourProjectName_Unified` (like *IssueManagement_Unified* for this sample).
> If you've selected the `--no-ui` option, this project will not be in your solution.
##### How to Run?
Set it as the startup project, run `Update-Database` command for the EF Core from Package Manager Console and run your application. Default username is `admin` and password is `1q2w3E*`.
#### Separated Deployment & Databases Scenario
In this scenario, there are three applications;
* `.IdentityServer` application is an authentication server used by other applications. It has its own `appsettings.json` that contains database connection and other configurations.
* `.HttpApi.Host` hosts the HTTP API of the module. It has its own `appsettings.json` that contains database connections and other configurations.
* `.Web.Host` host the UI of the module. This project contains an `appsettings.json` file, but it does not have a connection string because it never connects to the database. Instead, it mainly contains endpoint of the remote API server and the authentication server.
The diagram below shows the relation of the applications:
`.Web.Host` project uses OpenId Connect Authentication to get identity and access tokens for the current user from the `.IdentityServer`. Then uses the access token to call the `.HttpApi.Host`. HTTP API server uses bearer token authentication to obtain claims from the access token to authorize the current user.
##### How to Run?
You should run the application with the given order:
- First, run the `.IdentityServer` since other applications depends on it.
- Then run the `.HttpApi.Host` since it is used by the `.Web.Host` application.
- Finally, you can run the `.Web.Host` project and login to the application using `admin` as the username and `1q2w3E*` as the password.
@ -187,7 +187,7 @@ The solution has multiple test projects, one for each layer:
In addition, `.HttpApi.Client.ConsoleTestApp` is a console application (not an automated test project) which demonstrate the usage of HTTP APIs from a Dotnet application.
Test projects are prepared integration testing;
Test projects are prepared for integration testing;
* It is fully integrated to ABP framework and all services in your application.
* It uses SQLite in-memory database for EF Core. For MongoDB, it uses the [Mongo2Go](https://github.com/Mongo2Go/Mongo2Go) library.
@ -224,9 +224,9 @@ As different from the default structure, two new projects come into play: `.Iden
#### .IdentityServer Project
This project is used as an authentication server for other projects. `.Web` project uses OpenId Connect Authentication to get identity and access tokens for the current user. Then uses the access token to call the HTTP API server. HTTP API server uses bearer token authentication to obtain claims from the access token to authorize the current user.
This project is used as an authentication server for other projects. `.Web` project uses OpenId Connect Authentication to get identity and access tokens for the current user from the IdentityServer. Then uses the access token to call the HTTP API server. HTTP API server uses bearer token authentication to obtain claims from the access token to authorize the current user.
ABP uses the open source [IdentityServer4](https://identityserver.io/) framework for the authentication between applications. See [IdentityServer4 documentation](http://docs.identityserver.io) for details about the IdentityServer4 and OpenID Connect protocol.
@ -234,9 +234,7 @@ It has its own `appsettings.json` that contains database connection and other co
#### .HttpApi.Host Project
This project is an application that hosts the API of the solution.
It has its own `appsettings.json` that contains database connection and other configurations.
This project is an application that hosts the API of the solution. It has its own `appsettings.json` that contains database connection and other configurations.
#### .Web Project
@ -253,5 +251,10 @@ This project contains an `appsettings.json` file, but this time it does not have
You should run the application with the given order:
* First, run the `.IdentityServer` since other applications depends on it.
* Then run the `.HttpApi.Server` since it is used by the `.Web` application.
* Finally, you can run the `.Web` project and login to the application (using `admin` as the username and `1q2w3E*` as the password).
* Then run the `.HttpApi.Host` since it is used by the `.Web` application.
* Finally, you can run the `.Web` project and login to the application (using `admin` as the username and `1q2w3E*` as the password).
## What's Next?
- See [Getting Started With the ASP.NET Core MVC Template](../Getting-Started-AspNetCore-MVC-Template.md) to create a new solution and run it for this template.
- See the [ASP.NET Core MVC Tutorial](../Tutorials/AspNetCore-Mvc/Part-I.md) to learn how to develop applications using this template.