深入探讨：基于ABP框架与AdminLTE的Bootstrap Table权限管理实践（第四节）

时间：11-14 神话故事提交错误

本篇文章给大家谈谈深入探讨：基于ABP框架与AdminLTE的Bootstrap Table权限管理实践（第四节），以及对应的知识点，文章可能有点长，但是希望大家可以阅读完，增长自己的知识，最重要的是希望对各位有所帮助，可以解决了您的问题，不要忘了收藏本站喔。

在ABP框架中，仓储和服务被认为是最重要的领域之一。 ABP框架提供了创建和组装模块的基础。一个模块可以依赖于另一个模块，一个程序集可以被视为一个模块。

一个模块可以通过类来定义这个模块，而定义的类必须继承自已经转换好的AbpModule..net，才能通过反射获取这些程序集中的类或方法。

模块的调用往往涉及顺序。如果模块A依赖于模块B，那么模块B必须在模块A之前初始化。初始化相当于注册。例如，使用IocManager来注册一个注册类。

上面的方法中，我们将MyModule1注入到MyModule2中，在调用MyModule2的时候就可以初始化MyModule1了。

什么是依赖注入？百科全书说这个：“依赖注入是一种软件设计模式，其中一个或多个依赖项（或服务）通过引用依赖项对象来注入或传递，并成为客户端状态的一部分。这种模式将客户端依赖项的创建与其自己的行为，允许程序设计为松散耦合，遵循依赖倒置和单一责任的原则，与服务定位器模式相反，它允许客户端知道他们正在使用什么系统寻找依赖关系。”

如果不使用依赖注入技术，就很难管理依赖关系并发布结构良好的应用程序。

假设我们有一个应用程序服务，它使用存储库类将实体插入数据库。在这种情况下，应用程序服务类依赖于存储库类，如下

UserService 使用UserRepository 将Person 插入数据库。但这段代码存在一些问题。服务层UserService通过接口IUserRepository调用CreatePerson添加User对象。看似调用了IUserRepository接口，但实际上还是依赖于rush层的UserRepository。 UserService通过IUserRepository创建对象时，实际上实现了一个新的UserRepository区域，这和直接调用UserRepository没有什么区别。 IUserRepository 失去了意义。如果以后我们需要修改UserRepository类，但是UserService又依赖于它，这时候，我们就需要修改所有依赖于UserRepository的类。有了这种依赖关系，就很难对UserService 进行单元测试。违背了“高内聚、低耦合”的原则，在这里你可以看到服务层对仓储层有依赖。

为了解决这些问题，创建了以下版本。

这就是工厂模式。其实我之前在abp之前就经常使用这个方法。搭建框架非常麻烦，而且老是出错。 UserRepositoryFactory 是一个静态类。要创建并返回IUserRepositoryUserService 服务，无需直接创建UserRepository。

虽然这种方法是可行的，但仍然存在一些问题。

UserService 仍然依赖于UserRepositoryFactory。每个repository都要写一个工厂，非常繁琐。可测性还是不好。

有多种解决方案，包括属性注入、构造函数注入、依赖注入框架等。

以上就是abp中构造函数注入和属性输入的完美使用。现在，UserService 不知道哪些类实现了userRepository 以及如何创建它。谁需要使用UserService，首先创建一个IUserServiceUserService，并将其传递给构造函数。

有人可能会说，userRepository的下属类可能存在依赖关系。依赖注入框架通过自动管理依赖关系解决了这些问题。构造函数注入模式是提供类依赖关系的完美方式。这样，您就无法在不提供依赖项的情况下创建类的实例。它也是明确说明需要哪些类才能正常工作的有效方法。

然而，在某些情况下，该类依赖于另一个类，但没有它也可以生存。这通常适用于横切关注点（例如日志记录）。一个类可以没有工作日志，但如果您提供日志对象，它可以写入日志。在这种情况下，您可以将依赖项定义为公共属性，而不是将它们放在构造函数中。上面的例子中NullLogger.Instance是一个单例对象，它实现了ILogger接口但实际上什么都不做（不写Log。它实现了ILogger实例，方法体为空）。我们需要写日志的地方，只需要UserService.Logger=new Log4NetLogger();这样我们就可以写日志了。如果我们不写，我们就不会调用，因此是一个可选的依赖项。

几乎所有依赖注入框架都支持属性注入模式

ABP的依赖注入是基于Castle Windsor框架的。 Castle Windsor 是最成熟的DI 框架之一。依赖注入框架有很多，比如Unity、Ninject、StructureMap、Autofac等，之前用过Unity，但没有研究过其他的。依赖框架可以自动解决依赖关系。他们可以创建所有依赖项（递归地创建依赖项和依赖项）。所以你只需要根据注入模式编写类和类构造函数属性，剩下的让DI框架处理！在好的应用程序中，类甚至独立于DI 框架。整个应用程序只有几行代码或类与DI 框架显式交互。

有人说上面的例子看不到依赖注入。其实这里的UserService继承于IUserService，而IUserService又继承于IApplicationService。 abp在IApplicationService中封装了很多东西，ABP会自动注册它，因为它实现了IApplicationService接口（它只是一个空接口）。它将被注册为瞬态（每次使用时都会创建一个实例）。当您将IUserService 接口注入（使用构造函数注入）到类中时，会自动创建UserService 对象并将其传递给构造函数。

命名约定在这里非常重要。例如，您可以将名称PersonAppService 更改为MyPersonAppService 或包含“PersonAppService”后缀的其他名称，因为IPersonAppService 包含此后缀。但是您可以不遵循PeopleService 来命名您的服务类。如果这样做，它不会自动注册到IPersonAppService（它需要自行注册到DI 框架，而不是接口），因此如果需要，您应该手动注册。