- Introduced
- A quick example
- Other features
- Launch template
- How to use
Introduced
We always develop different applications for different needs. But at least on some levels, the common and similar functions are repeated over and over again. Such as: authorization, verification, exception handling, logging, localization, database connection management, settings management, audit logs and other functions. So we create architecture and best practices such as tiering and module architecture, DDD, Dependency injection, etc., and try to develop the application based on some conventions.
Since all of this is very time-consuming and difficult to create individually and can be applied to every project, many companies create their own frameworks that enable them to develop new applications quickly and without errors. But not all companies are lucky, most companies don't have the time, budget and team to develop a good framework. They may not even be able to create a framework because it is very difficult to write documents, train developers, and maintain frameworks.
The ASP. NET boilerplate (ABP) is an open source and rich document application framework that is designed to "develop a common framework for all companies, all developers!" ", and not just a framework, but also provides a powerful DDD-based architecture model and best practices.
A quick example
Let's take a look at the convenience of the ABP from a simple class:
public class taskappservice:applicationservice,itaskappservice{ private ReadOnly irepository<task> _ Taskrepository; Public Taskappservice (irepository<task> taskrepository) { _taskrepository = taskrepository; } [Abpauthorize (Mypermissions.updatingtasks)] Public Async Task Updatetask (updatetaskinput input) { logger.info ("Updating a task for input:" + input); var task = await _taskrepository.firstordefaultasync (input. TASKID); if (task = = null) { throw new Userfriendlyexception (L ("Couldnotfoundthetaskmessage")); } Input.mapto (Task);} }
In the example we see an application service method in DDD, where the application service method executes the user use case of the application at the presentation level. We can think of the Updatetask method as being called by Ajax. Let's take a look at the benefits of ABP:
- Dependency Injection: The ABP uses and provides a strong and compliant di framework. The application services described above are registered to the DI container as a temporary (one for each request requests), which simply injects all dependencies (such as irepository<task> in the example).
- Warehousing: ABP can create a default warehousing for each entity (such as irepository<task> in the example). The default warehousing contains many useful methods, such as the FirstOrDefault method in the example. We can easily expand the default warehousing as needed. Warehousing abstracts the DBMS and ORM and simplifies the data access logic.
- Authorization: The ABP can check the license. If the current user does not have the "Updating task" permission or is not logged in, the ABP will prevent them from accessing the Updatetask method. Use declarative features to simplify authorization, and of course there is another way of authorizing it.
- Verify: The ABP automatically checks whether input is null. Checks all properties of an input based on standard data annotation attributes and custom validation rules. If the request does not pass validation, a corresponding validation exception is thrown.
- Audit log: According to the Convention and configuration, each requested user, browser, IP address, call service, method, parameters, call time, execution time and other information will be automatically saved.
- Unit of work: In the ABP, each application service method is identified by default as a unit of work. Before the method starts, it automatically creates a connection and opens a transaction. If the method completes successfully, then the transaction is committed and the connection is released. Even with different repositories or methods, they can be atomic (transactional), and all changes to the entity are automatically saved when the transaction commits. So, as the example shows, we don't even have to call _repository. Update (Task) method.
- Exception handling: We rarely write exception handling in a Web application that uses an ABP. All exceptions are automatically handled by default. When an exception occurs, the ABP automatically records it and returns a corresponding result to the client. For example, an AJAX request that returns a JSON object to the client informs that an error has occurred. As the example shows, userfriendlyexception can hide specific exceptions from the client and display friendly information. It can also understand and handle client errors on the client side, and display the corresponding information to the user.
- LOG: As you can see, we could write the log with the Logger object defined in the base class. Log4net is used by default, but this is modifiable and configurable.
- Localization: Please note that we used the L method when throwing an exception. As a result, it automatically uses the appropriate localization information based on the user area. Of course, we need to define couldnotfoundthetaskmessage somewhere (see "localization" documentation for more information).
- Auto-mapping: The last line of code, we use the Mapto extension method of the ABP to map the input property to the Entity property. It uses the AutoMapper library to perform the mapping. Therefore, we can simply map from one object to another based on a naming convention.
- Dynamic Web API layer: Actually Taskappservice is a simple class (even if you don't need to inherit from Applicationservice). We usually wrap a Web API controller to expose methods to JavaScript clients, and the ABP will do this automatically at run time. Therefore, we can use the app service directly on the client.
- Dynamic JavaScript AJAX proxy: ABP Creates a JavaScript proxy method to invoke the app service just like a local call.
With such a simple class we can see the convenience of ABP. It is generally time-consuming to complete these tasks, but all of them are handled automatically by the ABP.
Other features
In addition to the example, the ABP provides a robust infrastructure and application model with the following additional features of the ABP:
- Modularity: Provides a powerful infrastructure to create reusable modules.
- Data filtering: Provides automatic data filtering to implement some patterns, like soft-delete and multi-tenancy.
- Multi-tenancy: fully supports multi-tenancy, consisting of a single database or a separate database per tenant.
- Setup Management: Provides an infrastructure to read/modify settings at the app, tenant, and user levels.
- Unit and integration testing: For testability purposes, the basic classes are provided to simplify unit testing and integration testing. Click here for more information.
Launch template
Start a new solution, create a layer, install a nuget package, create a simple layout and menu ... All of this is time-consuming work.
ABP provides a pre-created startup template that makes it easier to start a new solution. The template supports the architecture of the SPA (single page app) and MPA (multi-page MVC app). It also allows us to use different ORM tools.
How to use
ABP Open Source project on GitHub, distributed on NuGet. The startup template is the simplest way to use an ABP (as described in the documentation).
<<asp.net Boilerplate Documentation >> 1.1 Introduction