为了和2016年春节赛跑，完成该系列博客，我牺牲了今天中午的时间来完成该系列的第一篇————开篇介绍。开篇介绍嘛，读过大学教材的同学都知道，这玩意总是那么无聊，跟考试没关系，干脆直接跳过，呵呵，多么美好的大学时光啊！不过，现在想想，开篇介绍确实不怎么重要，它只是告诉我们今后我要开始讲什么了，主要讲什么，大概浏览下重点。
哦了，不扯了，时间不多了，干活！
本篇目录
介绍###
我们总是基于不同的需求创建不同的应用，但是在一定程度上，总在反复地实现通用而相似的结构。这些通用的结构包括授权，验证，异常处理，日志，本地化，数据库连接管理，设置管理，审计日志等。而且，我们总是在构建体系结构和最佳实践，比如分层和模块化架构，领域驱动设计（DDD），依赖注入等等。同时也在尝试基于惯例开发应用。
因为这些都是非常耗时的，并且对于每个项目单独创建是很困难的，所以很多公司都会创建自己私有的框架。通过使用私有的框架，他们总是可以快速地开发新的应用，同时应用的bug又会更少。当然了，不是所有的公司都是那么幸运了，你以为中国所有的公司都是BAT啊？！大多数公司还是没有时间，预算和团队来开发他们自己的私人框架。即使他们有可能构建这么一个框架，写文档，培训开发者以及维护也是很难的。
ABP是一个开源的且文档友好的应用框架，起始的想法是，“开发一款为所有公司和开发者通用的框架！”。它不仅仅是一个框架，更提供了一个基于DDD和最佳实践的健壮的体系模型。
快速样例###
一起来研究一个简单的类来看看ABP有哪些好处 ：
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);
}
}
这里我们看到了一个简单的应用服务方法。在DDD中，表现层直接使用应用服务来执行该应用的用例（其实就是一些操作方法）。我们还可以考虑使用Ajax调用上面的UpdateTask方法。
下面让我们总结一下ABP的一些优点：
- 依赖注入：ABP使用并提供了一个健壮而又传统的DI基础设施。因为上面的类是在一个应用服务中定义的，所以它会按照惯例约定短暂地（每个请求创建一次）注册到DI容器中。它也简单地注入了所有依赖（本例中注入了IRepository
）。 - 仓储：ABP可以为每一个实体创建一个默认的仓储（本例中是IRepository
）。默认的仓储有许多有用的方法，如本例中的 FirstOrDefault。我们也可以根据我们的需求轻易地扩展默认仓储。仓储抽象了DBMS和ORM，并简化了数据的访问逻辑。 - 授权：ABP可以检测权限。如果当前的用户没有“updating task”的权限或者没登录，那么ta不能访问UpdateTask方法。它使用声明式的特性简化了授权，而且还有其他的授权方法。
- 验证：ABP会自动检测输入是否为null。它也基于标准的数据注解特性和自定义的验证规则验证输入对象的所有属性。如果请求不合法，那么它会抛出一个合适的验证异常。
- 审计日志：用户，浏览器，IP地址，调用服务，方法，参数，调用时间，执行时长和其他的一些信息也会基于惯例和配置为每个请求自动地保存。
- 工作单元（Unit of Work）：在ABP中，每个应用服务方法默认视为一个工作单元。它会自动创建一个连接并在方法的开始位置开启一个事务。如果方法不报异常地成功完成了，那么事务会提交并且连接被释放。即使该方法使用了不同的仓储或者方法，它们全部也都是原子的（事务的）。当事务提交时，实体的所有改变都会自动保存。因此，正如这里展示的那样，我们甚至都不用调用_repository.Update(task)方法。
- 异常处理：在一个使用了ABP框架的Web应用中，我们基本上不用处理异常。所有的异常都会默认自动处理。如果一个异常发生了，那么ABP会自动地记录它，然后返回给客户端一个合适的结果。比如，如果这是一个Ajax请求，那么它会返回一个JSON到客户端，指明发生了一个错误。本例中使用了一个UserFriendlyException，这样就隐藏了客户端实际的异常信息。它也理解并处理客户端的错误，最后将合适的信息呈现给用户。
- 日志：我们可以使用在基类中定义的Logger来写日志。ABP默认使用了Log4Net，但是它是可改变的或可配置的。
- 本地化（Localization）：注意当抛出异常的时候我们使用了L方法。因此，它会基于当前用户的文化自动进行本地化。当然，我们可以在某些地方定义CouldNotFoundTheTaskMessage。
- 自动映射：上面的最后一行代码，我们使用了ABP的MapTo扩展方法将输入对象的属性映射到实体属性。它使用了AutoMapper库来执行映射。因此，我们可以基于命名惯例轻易地将属性从一个对象上映射到另一个对象上。我的AutoMapper系列学习博客：**http://www.cnblogs.com/farb/p/AutoMapperContent.html **。
- 动态Web API层：实际上，TaskAppService 是一个简单的类（甚至不需要从ApplicationService 继承）。我们一般会写一个Web API Controller包装器来将方法暴露给javascript客户端。ABP在运行时会自动完成。这样，我们可以从客户端直接使用应用服务方法。
- 动态Ajax代理：ABP创建了javascript代理方法，它们可以调用应用服务方法就像调用客户端的javascript方法一样简单。
在这么一个简单的类中，我们看到了ABP的优势。所有的这些任务正常情况下都是要花费很多时间的，但是所有的这些ABP自动帮我们完成了。
其他###
除了这个简单的例子，ABP也提供了一个健壮的基础设施和应用模型。下面是ABP的一下其他特征：
- 模块化：提供了一个健壮的基础设施来生成可复用的模块。
- 数据过滤器：提供了自动的数据过滤来实现一些模式，比如软删除和多租户。
- 多租户：支持单数据库、多客户形式的多租户。
- 设置管理：提供了健壮的基础设施类获得或者更改应用，租户和用户级别的设置。
- 单元测试和集成测试：基于可测试性构建，也提供了一些基类来简化单元测试和集成测试。
更多的特征，请认真阅读其他文档。
启动模板###
开始一个新的解决方案，创建层，安装nuget包，创建一个简单的布局和菜单...所有的这些都是非常耗时的。
ABP提供了一个预生成的启动模板，有了它，创建一个新的解决方案更容易了。模板支持SPA（单页应用）和MPA（多页应用）。而且，我们可以选择不同的ORM。
如何使用###
ABP的源码已经推送到了Github上，Nuget包也已经发布到了Nuget上。开始使用ABP最简单的方式就是使用ABP官网的模板创建项目，然后跟着文档来学习。