ABP Framework入门开发指南
最后，我们通过创建一个扩展的方法IModuleConfigurations来得到配置的引用。如下代码：
译者注：
模块配置是一个静态类，因为我们需要重复使用它。静态方法Mymodule返回的是一个配置接口，参数是ImoduleConfigurations接口。
现在，在其他模块中也可以配置我们自定义的这个MyModule模块了。
Configuration.Modules.MyModule().SampleConfig1 = false; Configuration.Modules.MyModule().SampleConfig2 = \
在某种意义上，MyModule需要这些配置，通过注射MyModuleConfig我们就可以使用这些值。
public class MyService : ITransientDependency {
private readonly MyModuleConfig _configuration;
public MyService(MyModuleConfig configuration) {
_configuration = configuration; }
public void DoIt() {
if (_configuration.SampleConfig2 == \ {
//... }
ABP框架中国小组(ABPFrameWorkGroup)版权所有 | 版本：1.014
ABP Framework入门开发指南
} }
这意味着，在abp框架的系统中，所有的模块都可以集中配置。
（1.1、1.2由阳铭翻译，1.3、1.4由天道翻译）
ABP框架中国小组(ABPFrameWorkGroup)版权所有 | 版本：1.015
ABP Framework入门开发指南
2 ABP公共结构
2.1 ABP依赖注入
如果你已经知道依赖注入的概念，构造函数和属性注入模式，你可以跳过这一节。 维基百科说：“依赖注入是一种软件设计模式，指一个或多个依赖（或服务）被注入，或通过引用传递，传入一个依赖对象（或客户端）并成为客户状态的一部分。模式通过自身的行为分离了客户依赖的创建，这允许程序设计是松耦合的，同时遵循依赖倒置和单一职责原则。与服务定位器模式直接进行对比，它允许客户了解他们用来查找依赖的机制。”。
如果不使用依赖注入技术，很难进行依赖管理、模块化开发和应用程序模块化。 2.1.1 传统方式的问题
在一个应用程序中，类之间相互依赖。假设我们有一个应用程序服务，使用仓储（repository）类插入实体到数据库。在这种情况下，应用程序服务类依赖于仓储（repository）类。看下例子：
public class PersonAppService {
private IPersonRepository _personRepository;
public PersonAppService() {
_personRepository = new PersonRepository(); }
public void CreatePerson(string name, int age) {
var person = new Person { Name = name, Age = age }; _personRepository.Insert(person); } }
ABP框架中国小组(ABPFrameWorkGroup)版权所有 | 版本：1.016
ABP Framework入门开发指南
PersonAppService使用PersonRepository插入Person到数据库。这段代码的问题： ? PersonAppService通过IPersonRepository调用CreatePerson方法，所以这方法
依赖于IPersonRepository，代替了PersonRepository具体类。但PersonAppService（的构造函数）仍然依赖于PersonRepository。组件应该依赖于接口而不是实现。这就是所谓的依赖性倒置原则。
? 如果PersonAppService亲自创建PersonPeository，这变得依赖到了一个特定的
IPersonRepository接口实现，且不能使用另一个实现进行工作。因此，从实现分离接口变得无意义，硬依赖使得代码基于紧耦合和低重用。硬依赖（hard-dependency）使得代码紧密耦合和较低的可重用。
? 我们可能需要在未来改变创建PersonRepository的方式。即，我们可能想让它创建
为单例(单一共享实例而不是为每个使用创建一个对象)。或者我们可能想要创建多个类实现IPersonRepository并根据条件创建对象。在这种情况下，我们需要修改所有依赖于IPersonRepository的类。
? 有了这样的依赖，很难(或不可能)对PersonAppService进行单元测试。
为了克服这些问题，可以使用工厂模式。因此，创建的仓储类是抽象的。看下面的代码：
public class PersonAppService {
private IPersonRepository _personRepository;
public PersonAppService() {
_personRepository = PersonRepositoryFactory.Create(); }
public void CreatePerson(string name, int age) {
var person = new Person { Name = name, Age = age }; _personRepository.Insert(person); } }
PersonRepositoryFactory是一个静态类，创建并返回一个IPersonRepository。这就是
ABP框架中国小组(ABPFrameWorkGroup)版权所有 | 版本：1.017
ABP Framework入门开发指南
所谓的服务定位器模式。以上依赖问题得到解决，因为PersonAppService不需要创建一个IPersonRepository的实现的对象，这个对象取决于PersonRepositoryFactory的Create方法。但是，仍然存在一些问题：
? 此时，PersonAppService取决于PersonRepositoryFactory。这是更容易接受，但
仍有一个硬依赖（hard-dependency）。
? 为每个库或每个依赖项乏味的写一个工厂类/方法。
? 测试性依然不好，由于很难使得PersonAppService使用mock实现
IPersonRepository。
2.1.2 解决方案
有一些最佳实践(模式)用于类依赖。 （1）构造函数注入(Constructor injection) 重写上面的例子，如下所示:
public class PersonAppService {
private IPersonRepository _personRepository;
public PersonAppService(IPersonRepository personRepository) {
_personRepository = personRepository; }
public void CreatePerson(string name, int age) {
var person = new Person { Name = name, Age = age }; _personRepository.Insert(person); } }
这被称为构造函数注入。现在，PersonAppService不知道哪些类实现IPersonRepository以及如何创建它。谁需要使用PersonAppService，首先创建一个
ABP框架中国小组(ABPFrameWorkGroup)版权所有 | 版本：1.018
百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说综合文库ABP开发教程(6)在线全文阅读。
相关推荐：