abp/docs/en/Startup-Templates/Mvc-Module.md

MVC Module Startup Template

This template can be used to create a reusable application module based on the module development best practices & conventions. It is also suitable for creating microservices (with or without UI).

How to Start With?

You can use the ABP CLI to create a new project using this startup template. Alternatively, you can directly create & download from the Get Started page. CLI approach is used here.

First, install the ABP CLI if you haven't installed before:

dotnet tool install -g Volo.Abp.Cli

Then use the abp new command in an empty folder to create a new solution:

abp new Acme.IssueManagement -t mvc-module

• Acme.IssueManagement is the solution name, like YourCompany.YourProduct. You can use single level, two-levels or three-levels naming.

Without User Interface

The template comes with a UI by default. You can use --no-ui option to not include the UI layer.

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:

Projects are organized as src, test and host folders:

• src folder contains the actual module which is layered based on DDD principles.
• test folder contains unit & integration tests.
• host folder contains applications with different configurations to demonstrate how to host the module in an application. These are not a part of the module, but useful on development.

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

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.

An IssueType enum and an IssueConts class (which may have some constant fields for the Issue entity, like MaxTitleLength) are good candidates for this project.

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

.Domain Project

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

An Issue entity, an IssueManager domain service and an IIssueRepository 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 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.

An IIssueAppService interface and an IssueCreationDto 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.

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

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.

You can delete this project if you don't want to support EF Core for your module.