在14,15年间带领几个不同的团队，交付了几个项目，在这个过程中，虽然几个项目的业务不一样，但是很多应用程序架构基础性的功能却是大同小异，例如认证、授权、请求验证、异常处理、DTO、日志、审计、定时任务、调度、多语言、应用配置管理等等这些功能。但是由于项目受限于进度、资源、团队成员的背景，在当时却难于做到各个项目的统一，只能用拷贝的方式，然后在不通的项目中各自再根据各自的需求去做改进。这促使我下定决心去整理实现一个通用的应用程序级别的框架，来提升项目交付的效率和质量。
在整理这个框架的过程中，参考了一些开源框架的设计和实现，无意中发现了ABP（ASP.NET Boilerplate）已经实现的正是我想要的，本着不重复造轮子的原则，在对ABP做了POC和评估后，在向整个评审小组展示时，尽管有诸多细节大家意见不尽相同，但对于整体框架却是少有的一致好评，在后来的项目交付中使用ABP也就是顺利成章的事了。当时ABP的版本还是0.5（现在的最新版本是3.5），尽管也踩了一些坑，但是总的来说还是大幅的提高了项目交付效率。
好了，废话不多说，我们进入正题。
什么是ABP
ABP(ASP.NET Boilerplate)是一个开源的应用程序框架，以帮助开发人员快速开发。但它又不仅仅是一个框架，更提供了一套基于DDD的架构模型和最佳实践。
快速示例
下面我们来研究一个最简单的示例来看看使用ABP好哪些好处
public class TaskAppService : ApplicationService, ITaskAppService
{
private readonly IRepository<Task> _taskRepository;
public TaskAppService(IRepository<Task> taskRepository)
{
_taskRepository = taskRepository;
}
[AbpAuthorize(MyPermissions.UpdateTasks)]
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("CouldNotFindTheTaskMessage"));
}
input.MapTo(task);
}
}这里我们看到的是一个Application Service类, TaskAppService, 里面定义了一个方法UpdateTask. Application Service在DDD的设计中是直接被展示层所调用的，简单来说，一个前端页面可以直接调用TaskAppService.UpdateTask.
就这个简单的示例，我们一起来看看使用ABP有哪些好处。
- 依赖注入 - ABP提供了一个惯用的DI基础框架，所谓惯用，就是大家平常使用的DI方式一致，保持大家的使用习惯。因为这个示例是在应用服务层，所以注入容器中的实例生命周期都是短时的（每个请求创建一次，生命周期与请求相同）。 它可以简单方便的注入任何依赖，比如在本示例中的IRepository
- 仓储 - ABP可以为每一个实体都创建一个默认仓储，在示例中是IRepository
- 授权- ABP可以使用声明式的方式来检查权限。在示例中，如果一个用户没有登录，或者没有“UpdateTasks”的权限，那么他将不能访问UpdateTask方法。 ABP不单单使用声明式的特性来检查权限，它还提供了其他的授权方式
- 请求验证- ABP自动的检查请求输入(input)是否为null, 并且可以基于标准的数据注解和自定义验证规则来检查输入中的属性是否合法。如果请求不合法，它将会抛出一个验证异常。
- 审计日志- ABP会基于惯例和配置，自动为每一个请求记录访问的用户、浏览器、IP地址、调用的服务、方法、参数、调用时间、耗时、和其它一些信息。
- 工作单元- 在ABP中，每个应用服务方法，都被默认视为一个工作单元. 在进入方法时，ABP会自动的打开连接并开启事务，如果方法在执行过程没有任何异常，并且成功完成，那么在退出方法时，ABP会自动提交事务并释放连接。不管方法中使用了一个还是多个仓储，他们都是原子的，在一个事务中，所有的实体改变都会在事务提交时自动保存。正如示例中所示，我们甚至都不用调用显示的 ‘_repository.Update(task)‘方法来保存数据更新。 不过我个人建议尽管可以不显示调用更新，但是从代码的可读性和可维护性还是显示的调用‘_repository.Update(task)‘方法
- 异常处理- 在ABP我们几乎不用手动的来处理异常，ABP会默认自动处理所有异常。如果有异常发生，ABP会自动的记录它，并返回合适的结果给客户端。例如，如果这是一个AJAX请求，它会返回一个JSON对象给客户端，并指明有一个错误发生。它会向客户端隐藏真实的异常，除非我们使用UserFriendlyException.
- 日志- 我们可以使用基类中定义的Logger对象来写日志。 ABP默认使用Log4Net来写日志，当然我们也可以通过修改配置来使用其他的日志框架。
- 本地化（多语言）- 在示例中，当抛出异常时，使用了"L"方法，它会根据用户文化配置自动进行本地化处理。
- 自动映射- 在示例的最后一行，我们使用了ABP的MapTo扩展方法来讲输入对象的属性映射到实体对象的属性。它使用了AutoMapper库来执行映射，我们可以很容易的基于命名约定（简单来讲就是属性名相同，当然也可以指定）来将一个对象的属性来映射到另一个对象的属性。通常不同层都会定义自己的数据对象模型，而在层与层之间进行数据交换时，就设计到不同数据对象的转换，这个时候就是AutoMapper大显身手的好时机。
- 动态API层- TaskAppService只是一个一般的类，通常我们需要写一个Web API Controller包装器来将TaskAppService的方法以API的形式暴露给客户端调用，但是ABP在运行时已经自动为AppService的方法生成了API接口，所以这样看起来，就像是客户端直接调用了AppService的方法（但实际不是）。
- 动态Javascript AJAX代理- ABP在前端为应用服务的调用创建了代理方法，这样就可以在前端像调用Javascript方法一样调用应用服务。
在示例中，我们可以看到使用ABP的优势，通常如果我们来做这些事情，会花费大量的时间，但是ABP框架都自动的为我们处理了。这里必须点个赞了。
此外，除了这个示例中展示的ABP的优势以外，ABP还提高了一个健壮的基础架构和应用模型。包括模块化、多租户、缓存、配置管理、调度和后台任务、数据过滤、领域时间、单元测试和集成测试等等。它让我们可以集中关注在业务实现上，而不用重复的去造轮子。
--
VS2017调试器无法附加到IIS进程(w3wp.exe)
问题描述：
当使用VS2017-> 调试->附加到进程来调试IIS进程(w3wp.exe)时，报错"无法附加到进程，已附加了一个调试器"
为了解决这个问题花了不少时间，在网上找了不少资料，试了7,8种方法都无效。最后用下面的方法解决了问题，供大家参考。
临时解决方法:
1 安装Debug Diagnostic Tool,
2 启动 "DebugDiag 2 Collection"
3 在process标签页中找到w3wp.exe, 右键选择detach debugger
原因:
我本机之前安装了Debug Diagnostic Tool, 此应用程序包含一个服务程序DbgSvc.exe, 和一个调试器DbgHost.exe, 服务程序DbgSvc.exe默认是自动启动的，从结果来看，启动此服务后，默认会把调试器DbgHost.exe附加到iis进程
彻底解决方法:
将服务Debug Diagnostic Service(DbgSvc.exe) 将启动类型设置为手动，这样默认不会启动此服务，需要的时候再启动
c# 动态实例化一个泛型类
动态实例化一个类，比较常见，代码如下
namespace ConsoleApp2
{
public class MyClass
{
}
}
Type classType = Type.GetType("ConsoleApp2.MyClass, AssemblyName");
var instance = Activator.CreateInstance(classType);
那如果这个类是泛型类，该如何实例化呢? 这里主要是要传递泛型参数
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);
