【Net】ABP框架学习之它并不那么好用

前言

 上一篇文章介绍了ABP的Web API，本文在继续介绍ABP的其余内容。

在ABP中，WEBAPI是一个值得用的东西。但其余东西，就不必定是那么好用了。

由于越深刻的学习ABP，你就越会发现，它自身有着很是强的设计约束，而而微软的框架已经有必定的约束了，再使用一套附加约束，显然会更辛苦。

下面咱们看一下ABP的Controller。

建立项目

首先，咱们建立一个MVC项目，AbpMvcController。

而后引用Abp.Web.Mvc。

使用了ABP后，必须修改WebApiApplication的继承类，因此，原来的初始化的路由等等信息，要换个地方写了，下面咱们看看变化。

将WebApiApplication改成继承Abp.Web.AbpWebApplication；Global.asax修改以下：

using Abp.Web;
using AbpMvcController;
using System;
using System.Web;
[assembly: PreApplicationStartMethod(typeof(PreStarter), "Start")]
namespace AbpMvcController
{
    public class WebApiApplication : Abp.Web.AbpWebApplication<StartServiceModule>
    {
        protected override void Application_Start(object sender, EventArgs e)
        {
            base.Application_Start(sender, e);
        } 
    }
​
    public static class PreStarter
    {
        public static void Start()
        { 
            WebApiApplication.AbpBootstrapper.PlugInSources.AddToBuildManager(); 
        }
    } 
}

而后在App_Start文件夹新建StartModule，StartModule继承 AbpModule。

而后把在Global.asa中删除路由注册等信息，在StartModule中，重写出来。

PS：由于建立的是MVC项目，因此咱们添加相应的依赖——[DependsOn(typeof(Abp.Web.AbpWebModule),typeof(AbpWebMvcModule))]。

代码以下：

[DependsOn(typeof(Abp.Web.AbpWebModule),typeof(AbpWebMvcModule))]
public class StartModule : AbpModule
{
    public override void PreInitialize()
    {
        Configuration.Modules.AbpWeb().AntiForgery.IsEnabled = false;
        Configuration.Modules.AbpWebCommon().SendAllExceptionsToClients = true; 
    }
    public override void Initialize()
    {
        IocManager.RegisterAssemblyByConvention(Assembly.GetExecutingAssembly());
        AreaRegistration.RegisterAllAreas();
        RouteConfig.RegisterRoutes(RouteTable.Routes); 
        BundleConfig.RegisterBundles(BundleTable.Bundles);
    }
    public override void PostInitialize()
    {
        GlobalConfiguration.Configuration.Filters.Add(new ExceptionFilter());
    }
    public override void Shutdown()
    {
    }
}

如今咱们尝试运行项目，结果项目成功启动，以下图。

即，咱们虽然修改了WebApiApplication的继承类，但依然能够正常访问建立项目时，自动生成的Controller。

也就是说，ABP并无改变MVC的逻辑。

AbpController

ABP中提供了一个AbpController，它至关于对对MVC的Controller的扩展。

如今，咱们找到HomeController，修改它的继承，而后运行项目。

项目正常运行。

----------------------------------------------------------------------------------------------------

如今咱们编写一个AuthorizeAttribute，而后放到这个继承AbpController的Controller上；代码以下：

[CustomAuthorize]
public class HomeController : AbpController
{
    public ActionResult Index()
    {
        ViewBag.Title = "Home Page";
​
        return View();
    }
}

而后咱们断点CustomAuthorizeAttribute的AuthorizeCore函数。

测试结构发现，断点能够被命中。

即，MVC的受权特性还能够正常使用。

----------------------------------------------------------------------------------------------------

ABP也提供了一个受权特性——AbpMvcAuthorize；很好理解，它是AuthorizeAttribute的一个扩展，和上面的AbpController同样。

结语

整体上来讲，ABP框架对微软的WebApi作出了很好的封装，提供了比较高级的扩展，即，动态建立WebApi，它切实的简化了代码。

但，对Controller，它并无提供过高级的功能，就是一些简单的扩展和再封装。

那么，如要使用ABP来开发MVC，就须要在学习微软MVC的基础上，再去学习ABP的方言了。

说实话，这样作有点累；因此，开发项目时，使用微软的MVC结构便可，由于网上有丰富的资源可用。

关于ABP的其余功能：

ABP的日志：ABP的日志由于没办法扩展到没引用ABP的类库里，而引用ABP又要引用一堆类库；因此，全系统使用ABP的日志几乎是不可能的，即，它意义不大，仍是本身封装日志比较好。

ABP提供的EF：ABP提供的EF因其使用和配置太过繁琐，支持的功能又不是特别全面；且设计理念上，只有部分DDD的思想，而后，它还很难扩展；因此，基本上能够抛弃了，由于根本无法和业务作最完美的结合。事实上，随便找的开源的EF再封装框架都比ABP的好理解，好调用。

ABP的依赖注入：ABP的依赖注入也是依赖Castle，那就是说咱们彻底能够直接使用Castle，这样，效果比用他封装的好；若是项目可使用Core框架开发，那直接使用Core的依赖注入就能够了，这个比ABP的强太多了。

----------------------------------------------------------------------------------------------------

代码已经传到Github上了，欢迎你们下载。

Github地址：https://github.com/kiba518/AbpMvcController

----------------------------------------------------------------------------------------------------

注：此文章为原创，任何形式的转载都请联系做者得到受权并注明出处！
若您以为这篇文章还不错，请点击下方的【推荐】，很是感谢！

http://www.javashuo.com/article/p-mgfjlkpf-dm.html