Shulou(Shulou.com)06/03 Report--

Editor to share with you the ABP framework of the architecture and module system example analysis, I believe that most people do not know much about it, so share this article for your reference, I hope you will learn a lot after reading this article, let's go to understand it!

DDD layering

In order to reduce complexity and improve code reusability, hierarchical architecture is a widely accepted technology.

In order to implement a hierarchical architecture, ABP follows the principles of DDD (Domain driven Design) and will be divided into four levels:

Presentation layer (Presentation): provides a user interface for user interaction.

Application layer (Application): coordinate between the presentation layer and the domain layer, and coordinate business objects to perform specific application tasks. It does not contain business logic.

Domain layer (Domain): includes business objects and business rules, which is the core layer of the application.

Infrastructure layer (Infrastructure): provides common technologies to support higher layers. For example, warehousing (Repository) in the infrastructure layer can achieve database interaction through ORM.

Depending on the actual need, there may be additional layers. For example:

Distributed Services layer (Distributed Service): used to expose application programming interfaces for remote clients to invoke. For example, through ASP.NET Web API and WCF to achieve.

These are common domain-centric hierarchical architectures. There may be slight differences in implementation between different projects.

The architecture of ABP

A simple solution that consists of roughly 5 projects:

Each layer can be implemented with one or more assemblies.

1. Domain layer (Domain)

The domain layer is the business layer, which is the core of a project, and all business rules should be implemented in the domain layer.

two。 Entity (Entity)

Entities represent data and operations in the business domain and, in practice, are used to map to database tables.

3. Storage (Repository)

Warehousing is used to operate the database for data access. The warehouse interface is defined at the domain level, and the implementation class for the warehouse should be written at the infrastructure layer.

4. Domain Services (Domain service)

When dealing with business rules that span two (or more) entities, they should be written in the domain service method.

5. Domain event (Domain Event)

Domain events can be triggered when certain situations occur at the domain level, and they can be captured and processed in the appropriate places.

6. Unit of work (Unit of Work)

A unit of work is a design pattern for maintaining a list of business objects that have been modified (such as additions, deletions, updates, etc.). It is responsible for coordinating the persistence and concurrency of these business objects.

Application layer (Application)

The application layer provides some application service (Application Services) methods for the presentation layer to call. An application service method takes a DTO (data transfer object) as an input parameter, uses this input parameter to perform specific domain-level operations, and returns another DTO as needed. Between the presentation layer and the domain layer, entity (Entity) objects should not be received or returned, and DTO mapping should be performed. An application service method is usually thought of as a Unit of Work. The verification of user input parameters should also be implemented in the application layer. ABP provides an infrastructure that makes it easy to validate input parameters. It is recommended that a tool such as AutoMapper be used for mapping between entities and DTO.

Infrastructure layer (Infrastructure)

When warehousing interfaces are defined in the domain layer, they should be implemented in the infrastructure layer. You can use ORM tools, such as EntityFramework or NHibernate. The base class of ABP already provides support for both ORM tools. Database migration is also used at this layer.

WEB and presentation layer (Web & Presentation)

The Web layer is implemented using ASP.NET MVC and Web API. Can be used for multi-page applications (MPA) and single-page applications (SPA), respectively.

In SPA, all resources are loaded into the client browser at once (or only the core resources are loaded first, other resources are loaded lazily), and then the data is obtained by calling the server-side WebApi interface through AJAX, and then the HTML code is generated according to the data. The entire page will not be refreshed. There are many JS frameworks for SPA, such as AngularJs, DurandalJs, BackboneJs, EmberJs. ABP can use any similar front-end framework, but ABP provides some helper classes that make it easier for us to use AngularJs and DurandalJs.

In a classic multi-page application (MPA), the client makes a request to the server, and the server-side code (ASP.NET MVC controller) gets the data from the database and generates the HTML using the Razor view. These generated HTML pages are sent back to the client for display. Every time a new page is displayed, the whole page is refreshed.

SPA and MPA involve completely different architectures and different application scenarios. A management background is suitable for SPA, while blogs are more suitable for MPA, because it is easier to be crawled by search engines.

SignalR is a perfect tool for sending push notifications from the server to the client. It can provide users with a rich real-time experience.

There are already many client-side Javascript frameworks or libraries, of which JQuery is the most popular, and it has thousands of free plug-ins. Using Bootstrap makes it easier for us to write Html and CSS.

ABP also implements the automatic creation of Javascript code functions according to the Web API interface to simplify the call of JS to Web Api. And generate the server-side menus, languages, settings, etc., to the JS side. (but in my own project, I turn off these auto-generation features because they are not very necessary, and they affect performance.)

ABP automatically handles the exceptions returned by the server and prompts the user with a friendly interface.

ABP module system

The ABP framework provides the basis for creating and assembling modules, one of which can be dependent on another. In general, an assembly can be seen as a module. In the ABP framework, a module is defined by a class that inherits from AbpModule.

Translator's note: if you have studied Orchard, you should know the power of the module module. The essence of the module is reusability, you can call it anywhere, and by implementing the module, the module you write can also be used by others.

Assembly assembly: an Assembly is a collection of information such as the name, version number, self-description, file association, and file location of the program. The simplest understanding is that a dll generated by a class library you write yourself can be regarded as an assembly, which can include many classes, classes, methods, and so on.

.net can get classes and methods in an assembly through reflection.

In the following example, we develop a MybolgApplication module that can be called in several different applications, with the following code:

Public class MyBlogApplicationModule: AbpModule / / defines {public override void Initialize () / / initializes {IocManager.RegisterAssemblyByConvention (Assembly.GetExecutingAssembly ()); / / the writing of this line of code is basically the same. Its purpose is to register a specific class or interface of the current assembly with the dependency injection container. }}

The ABP framework scans all assemblies and finds all imported classes in the AbpModule class. If you have created an application containing multiple assemblies, for ABP, our recommendation is to create a Module (module) for each assembly.

Life cycle event

In one application, the abp framework calls some specified methods of the Module module to start and close the module. We can overload these methods to accomplish our own tasks.

The ABP framework calls these methods through the order of dependencies. If module A depends on module B, then module B should be initialized before module A, and the method order for module startup is as follows:

PreInitialize-B

PreInitialize-A

Initialize-B

Initialize-A

PostInitialize-B

PostInitialize-A

The following is a description of the specific method:

1.PreInitialize

Preinitialization: this method is called for the first time when the application is started. You can specify your own special code in this method before dependency injection registration. For example: if you create a traditional registration class, you need to register the class first (use IocManager to register the registration class), and you can register events to the IOC container. Wait.

2.Initialize

Initialization: this method is usually used to register dependency injection, which is usually achieved through the IocManager.RegisterAssemblyByConvention method. If you want to implement custom dependency injection, please refer to the relevant documentation for dependency injection.

3.PostInitialize

Commit initialization: the last method, which is used to resolve dependencies.

4.Shutdown

Close: this method is called when the application is closed.

Module dependency (Module dependencies)

The Abp framework automatically parses dependencies between modules, but we recommend that you explicitly declare dependencies by overloading the GetDependencies method.

[DependsOn (typeof (MyBlogCoreModule))] / / define dependency public class MyBlogApplicationModule through annotations: AbpModule {public override void Initialize () {IocManager.RegisterAssemblyByConvention (Assembly.GetExecutingAssembly ());}}

For example, in the above code, we declare the dependency between MyBlogApplicationModule and MyBlogCoreModule (through the attribute attribute), the application module MyBlogApplicationModule depends on the MyBlogCoreModule core module, and the MyBlogCoreModule core module is initialized before the MyBlogApplicationModule module.

How to customize the module method

There may be methods in our own defined module that may be called by other modules that depend on the current module. The following example assumes that module 2 depends on module 1 and wants to call the method of module 1 when preinitializing.

Public class MyModule1: AbpModule {public override void Initialize () / / initialization module {IocManager.RegisterAssemblyByConvention (Assembly.GetExecutingAssembly ()); / / here, register for dependency injection. } public void MyModuleMethod1 () {/ / write the custom method here. }} [DependsOn (typeof (MyModule1))] public class MyModule2: AbpModule {private readonly MyModule1 _ myModule1; public MyModule2 (MyModule1 myModule1) {_ myModule1 = myModule1;} public override void PreInitialize () {_ myModule1.MyModuleMethod1 (); / / call the method of MyModuleMethod1. } public override void Initialize () {IocManager.RegisterAssemblyByConvention (Assembly.GetExecutingAssembly ());}}

In this way, module 1 is injected into module 2, so module 2 can call the methods of module 1.

These are all the contents of the article "sample Analysis of Architecture and Module Systems in the ABP Framework". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.