@ -18,11 +18,28 @@ public class BlogModule : AbpModule
### Conventional Registration
ABP introduces conventional service registration. To register all services of a module, you can simple call ``AddAssemblyOf`` extension method as shown below:
ABP introduces conventional service registration. You should do nothing to register services by convention. It's automatically done. If you want to disable it, you can set `SkipAutoServiceRegistration` to `true` by overriding the `PreConfigureServices` method.
````C#
public class BlogModule : AbpModule
{
public override void PreConfigureServices(ServiceConfigurationContext context)
{
SkipAutoServiceRegistration = true;
}
}
````
Once you skip auto registration, you should manually register your services. In that case, ``AddAssemblyOf`` extension method can help you to register all your services by convention. Example:
````c#
public class BlogModule : AbpModule
{
public override void PreConfigureServices(ServiceConfigurationContext context)
{
SkipAutoServiceRegistration = true;
}
public override void ConfigureServices(ServiceConfigurationContext context)
{
context.Services.AddAssemblyOf<BlogModule>();
@ -30,19 +47,19 @@ public class BlogModule : AbpModule
}
````
``AddAssemblyOf`` extension method takes a type (generally the type of the module class) and registers all services in the same assembly with given type by convention. The section below explains conventions and configurations.
The section below explains the conventions and configurations.
#### Inheritly Registered Types
#### Inherently Registered Types
Some specific types are registered to dependency injection by default. Examples:
* Module classes implement ``IAbpModule`` interface are registered as singleton.
* MVC controllers inherit ``Controller`` (or ``AbpController``) class are registered as transient.
* MVC page models inherit ``PageModel`` (or ``AbpPageModel``) class are registered as transient.
* MVC view components inherit ``ViewComponent`` (or ``AbpViewComponent``) class are registered as transient.
* Application services implement ``IApplicationService`` interface (or inherit ``ApplicationService`` class) are registered as transient.
* Repositories implement ``IRepository`` interface are registered as transient.
* Domain services implement ``IDomainService`` interface are registered as transient.
* Module classes are registered as singleton.
* MVC controllers (inherit ``Controller`` or ``AbpController``) are registered as transient.
* MVC page models (inherit ``PageModel`` or ``AbpPageModel``) are registered as transient.
* MVC view components (inherit ``ViewComponent`` or ``AbpViewComponent``) are registered as transient.
* Application services (implement ``IApplicationService`` interface or inherit ``ApplicationService`` class) are registered as transient.
* Repositories (implement ``IRepository`` interface) are registered as transient.
* Domain services (implement ``IDomainService`` interface) are registered as transient.
Example:
@ -129,16 +146,13 @@ public class TaxCalculator : ITaxCalculator, ITransientDependency
#### Manually Registering
In some cases, you may need to register a service to IServiceCollection manually, especially if you need to use custom factory methods or singleton instances. In that case, you can directly add services just as <ahref="https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection"target="_blank">Microsoft documentation</a> describes. Example:
In some cases, you may need to register a service to the `IServiceCollection` manually, especially if you need to use custom factory methods or singleton instances. In that case, you can directly add services just as <ahref="https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection"target="_blank">Microsoft documentation</a> describes. Example:
````C#
public class BlogModule : AbpModule
{
public override void ConfigureServices(ServiceConfigurationContext context)
@ -148,25 +162,6 @@ public class BlogModule : AbpModule
}
````
Finally, you may want to add a single class or a few classes by ABP's conventions, but don't want to use ``AddAssemblyOf``. In that case, you can use ``AddType`` and ``AddTypes`` extension method which implements ABP's conventions for given type(s). Example:
````C#
public class BlogModule : AbpModule
{
public override void ConfigureServices(ServiceConfigurationContext context)
## Getting Started ABP With AspNet Core MVC Web Application
This tutorial explains how to start ABP from scratch with minimal dependencies. You generally want to start with a ***startup template*** (TODO: link).
This tutorial explains how to start ABP from scratch with minimal dependencies. You generally want to start with a ***[startup template](https://abp.io/Templates)***.
``AppModule`` is a good name for the startup module for an application.
A module class can register services to Dependency Injection by overriding ``ConfigureServices`` method as shown here. ``AddAssemblyOf<...>`` is a special extension method of ABP that registers all services in an assembly by convention (see [dependency injection document](Dependency-Injection.md)). While this is optional, a module generally registers some services.
ABP packages define module classes and a module can depend on another module. In the code above, our ``AppModule`` depends on ``AbpAspNetCoreMvcModule`` (defined by Volo.Abp.AspNetCore.Mvc package). It's common to add a ``DependsOn`` attribute after installing a new ABP nuget package.
Instead of Startup class, we are registering dependencies and configuring AspNet Core pipeline in this module class.
Instead of Startup class, we are configuring ASP.NET Core pipeline in this module class.
### The Startup Class
@ -127,7 +120,7 @@ If you run the application, you will see a "Hello World!" message on the page.
Derived ``HomeController`` from ``AbpController`` instead of standard ``Controller`` class. This is not required, but ``AbpController`` class has useful base properties and methods to make your development easier.
### Using Autofac as Dependency Injection Framework
### Using Autofac as the Dependency Injection Framework
While AspNet Core's Dependency Injection (DI) system is fine for basic requirements, Autofac provides advanced features like Property Injection and Method Interception which are required by ABP to perform advanced application framework features.
This tutorial explains how to start ABP from scratch with minimal dependencies. You generally want to start with a ***startup template*** (TODO: link).
This tutorial explains how to start ABP from scratch with minimal dependencies. You generally want to start with a ***[startup template](https://abp.io/Templates)***.
### Create A New Project
@ -28,18 +28,13 @@ namespace AbpConsoleDemo
{
public class AppModule : AbpModule
{
public override void ConfigureServices(ServiceConfigurationContext context)
{
context.Services.AddAssemblyOf<AppModule>();
}
}
}
````
``AppModule`` is a good name for the startup module for an application.
A module class can register services to Dependency Injection by overriding ``ConfigureServices`` method as shown here. ``AddAssemblyOf<...>`` is a special extension method of ABP that registers all services in an assembly by convention (TODO: link to DI document). While this is optional, a module generally registers some services.
### Initialize The Application
The next step is to bootstrap the application using the startup module created above:
@ -110,7 +105,8 @@ namespace AbpConsoleDemo
application.Initialize();
//Resolve a service and use it
var helloWorldService = application.ServiceProvider.GetService<HelloWorldService>();
@ -32,19 +32,7 @@ public class BlogModule : AbpModule
}
````
You can register dependencies one by one as stated in Microsoft's <ahref="https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection"target="_blank">documentation</a>. ABP has also a **conventional dependency registration system** which allows you to register all services in your assembly automatically. ``ConfigureServices`` methods of most modules contain such an expression to register all services in given module:
````C#
public class BlogModule : AbpModule
{
public override void ConfigureServices(ServiceConfigurationContext context)
{
context.Services.AddAssemblyOf<BlogModule>();
}
}
````
See [Dependency Injection](Dependency-Injection.md) documentation for more about the dependency injection system.
You can register dependencies one by one as stated in Microsoft's <ahref="https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection"target="_blank">documentation</a>. Bu ABP has a **conventional dependency registration system** which automatically register all services in your assembly. See the [dependency Injection](Dependency-Injection.md) documentation for more about the dependency injection system.
You can also configure other services and modules in this method. Example:
@ -53,8 +41,6 @@ public class BlogModule : AbpModule
{
public override void ConfigureServices(ServiceConfigurationContext context)
{
context.Services.AddAssemblyOf<BlogModule>();
//Configure default connection string for the application
@ -124,19 +110,6 @@ You can also perform startup logic if your module requires
Lastly, you can override ``OnApplicationShutdown`` method if you want to execute a code while application is beign shutdown.
#### Alternative to Deriving from AbpModule Class
If you want to not derive your modules from ``AbpModule`` class for some reason, you can create a class and implement ``IAbpModule`` interface. This is the minimal interface required by ABP. If you want to handle other life cycle events as described above, you can implement additional interfaces:
* ``IPreConfigureServices``
* ``IPostConfigureServices``
* ``IOnPreApplicationInitialization``
* ``IOnApplicationInitialization``
* ``IOnPostApplicationInitialization``
* ``IOnApplicationShutdown``
However, deriving from ``AbpModule`` class is simpler since it implements all of these interfaces as virtual empty methods, so you can simple override which you need.
### Module Dependencies
In a modular application, it's typical a module depends on other modules. An Abp module must declare ``[DependsOn]`` attribute if it depends on another module, as shown below: