In 14, 15 years led several different teams, delivered several projects, in this process, although several projects of the business is different, but many of the application architecture basic functions are similar, such as authentication, authorization, request authentication, exception handling, DTO, log, audit, scheduled tasks, scheduling, multi-language, Apply configuration management and so on. However, because the project is limited by the progress, resources, team members background, at that time it is difficult to achieve the unity of each project, can only be copied, and then in the non-pass project in accordance with their respective needs to do the improvement. This prompted me to make up my mind to implement a common application-level framework to improve the efficiency and quality of project delivery.
In the process of organizing this framework, referring to the design and implementation of some open source frameworks, I stumbled upon the fact that the ABP (ASP. NET boilerplate) has been implemented exactly what I wanted, in the principle of not duplicating wheels, and after the POC and evaluation of the ABP, when it was presented to the entire panel, Although there are a lot of details that people disagree with, the overall framework is rarely well received, and the use of ABP in subsequent project deliveries is a smooth Cheng Zhang. At the time, the ABP version was still 0.5 (now the latest version is 3.5), although some pits were also stepped up, but overall the project delivery efficiency was greatly improved.
Well, don't say much nonsense, we get to the point.
What is ABP
The ABP (ASP. Boilerplate) is an open-source application framework to help developers develop quickly. But it's not just a framework, it provides a set of DDD-based architecture models and best practices.
Quick Example
Let's look at one of the simplest examples to see what the benefits of using an ABP are.
PublicClass Taskappservice:applicationservice, itaskappservice{ private readonly irepository<task> _taskrepository; public TaskAppService (irepository<task> taskrepository) {_taskrepository = taskrepository;} [Abpauthorize (Mypermissions.updatetasks)] public async Task UpdateTask "Updating a task for input:" + Input); var task = await _taskrepository.firstordefaultasync (input. TASKID); if (task = null) {throw new Userfriendlyexception (L ( "couldnotfindthetaskmessage"));} input. Mapto (Task); }}
What we see here is a application service class, Taskappservice, which defines a method updatetask. Application service in the design of DDD is directly called by the presentation layer, in short, a front-end page can be directly called Taskappservice.updatetask.
For this simple example, let's look at the benefits of using an ABP.
- Dependency Injection -ABP provides a common DI framework, so-called idiomatic, that is, everyone uses the same di way, keeping everyone's habits. Because this example is in the Application service layer, the instance life cycle in the injected container is short (each request is created once and the life cycle is the same as the request). It can be easily injected with any dependency, such as the irepository in this example
- Warehousing -ABP can create a default warehousing for each entity, in the example irepository
- Authorization -the ABP can use declarative methods to check permissions. In the example, if a user is not logged on, or does not have the "updatetasks" permission, then he will not be able to access the Updatetask method. The ABP does not only use declarative features to check permissions, it also provides additional authorization methods
- Request Validation -The ABP automatically checks that the request input (input) is null, and can check that the attributes in the input are legitimate based on standard data annotations and custom validation rules. If the request is not valid, it will throw a validation exception.
- Audit Log -the ABP automatically logs each request for access to the user, browser, IP address, service, method, parameters, call time, duration, and other information, based on Convention and configuration.
- unit of work -in an ABP, each app service method is treated by default as a unit of work. When the method is entered, the ABP automatically opens the connection and turns on the transaction, and if the method does not have any exceptions during execution and completes successfully, the ABP automatically commits the transaction and releases the connection when the method exits. Regardless of whether one or more warehouses are used in the method, they are atomic, and in one transaction, all entity changes are automatically saved when the transaction commits. As shown in the example, we don't even have to invoke the ' _repository ' displayed. Update (Task) ' method to save data updates. But I personally recommend that although you can not display the call update, the readability and maintainability of the code is displayed in the call ' _repository. Update (Task) ' method
- exception Handling -at ABP We rarely handle exceptions manually, and the ABP automatically handles all exceptions by default. If an exception occurs, the ABP automatically logs it and returns the appropriate results to the client. For example, if this is an AJAX request, it returns a JSON object to the client and indicates that an error occurred. It hides the real exception from the client unless we use Userfriendlyexception.
- Log -we can use the Logger object defined in the base class to write the log. The ABP uses log4net to write logs by default, but we can also use other log frames by modifying the configuration.
- localization (multi-language)-in the example, when an exception is thrown, an "L" method is used, which is automatically localized according to the user culture configuration.
- Auto-mapping -in the last line of the example, we used the Mapto extension method of the ABP to map the properties of the input object to the properties of the entity object. It uses the AutoMapper library to perform the mapping, and we can easily map the properties of an object to the properties of another object based on the naming convention, which is simply the same as the property name, or, of course, the specified one. Usually different layers will define their own data object model, and in the layer and layer of data exchange between the design to different data object conversion, this time is the good time to AutoMapper.
- Dynamic API Layer -Taskappservice is just a generic class, usually we need to write a Web API controller wrapper to expose the Taskappservice method to the client call in the form of an API, However, the ABP has automatically generated API interfaces for the Appservice method at run time, so it looks like the client has called the Appservice method directly (but not actually).
- dynamic JavaScript ajax proxy -ABP creates a proxy method on the front-end for an application service invocation, so that the application service can be invoked on the front-end like a JavaScript method.
In the example, we can see the advantages of using an ABP, which usually takes a lot of time if we do these things, but the ABP framework is automatically processed for us. It has to be a great place to be.
In addition to the advantages of the ABP shown in this example, the ABP also improves a robust infrastructure and application model. Includes modularity, multi-tenancy, caching, configuration management, scheduling and background tasks, data filtering, domain time, unit testing, integration testing, and more. It allows us to focus on the implementation of the business without having to reinvent the wheel.
--
VS2017 debugger cannot attach to IIS process (w3wp.exe)
Problem Description:
Error "Unable to attach to process, one debugger attached" when attaching to process to debug IIS process (w3wp.exe) using vs2017-> Debug
In order to solve this problem took a lot of time, on the internet to find a lot of information, tried 7, 8 methods are invalid. Finally, the following method is used to solve the problem, for everyone's reference.
Interim workaround:
1 Installing the Debug Diagnostic Tool,
2 Start "DebugDiag 2 Collection"
3 Find W3wp.exe in the Process tab, right-select Detach debugger
Reason:
I installed the debug Diagnostic Tool before this machine, this application contains a service program DbgSvc.exe, and a debugger DbgHost.exe, The service program DbgSvc.exe is automatically started by default, and as a result, when this service is started, the debugger DbgHost.exe is appended to the IIS process by default
A thorough solution:
Set the startup type to manual for the Service Debug Diagnostic service (DbgSvc.exe) so that the service is not started by default and starts when needed
Dynamic instantiation of a generic class---C #
Dynamic instantiation of a class, more common, the code is as follows
namespace consoleapp2{public class MyClass { }}
Type ClassType = Type.GetType ("Consoleapp2.myclass, AssemblyName"); var instance = Activator.CreateInstance ( ClassType);
What if this class is a generic class, how do I instantiate it? The main point here is to pass the generic parameter
namespace consoleapp2{public class mygenericclass<t> { }}
Type ClassType = Type.GetType ("Consoleapp2.mygenericclass' 1, AssemblyName"); Type Constructedtype = Classtype.makegenerictype (typeof (T)), var instance = Activator.CreateInstance (Constructedtype) ;
ABP Framework-Introduction VS2017 debugger cannot attach to IIS process (w3wp.exe) C # Dynamic instantiation of a generic class