配置ABP
配置是通过在自己模块的PreInitialize方法中来实现的
代码示例如下：
public class SimpleTaskSystemModule : AbpModule
{
public override void PreInitialize()
{
//在你的应用中添加语言包，这个是英语和作者的土耳其语。
Configuration.Localization.Languages.Add(new LanguageInfo("en", "English", "famfamfam-flag-england", true));
Configuration.Localization.Languages.Add(new LanguageInfo("tr", "Türkçe", "famfamfam-flag-tr"));
Configuration.Localization.Sources.Add(
new XmlLocalizationSource(
"SimpleTaskSystem",
HttpContext.Current.Server.MapPath("~/Localization/SimpleTaskSystem")
)
);
//配置导航和菜单
Configuration.Navigation.Providers.Add<SimpleTaskSystemNavigationProvider>();
}
public override void Initialize()
{
IocManager.RegisterAssemblyByConvention(Assembly.GetExecutingAssembly());
}
}
</div>
和orchard类似，abp框架一开始就被设计成模块化的，不同的模块可以通过abp框架来进行配置。举个例子吧，不同的模块都可以添加导航，通过导航添加菜单项到自己定义的主菜单，具体的细节大家可以参照：
本地化：http://www.aspnetboilerplate.com/Pages/Documents/Localization
导航：http://www.aspnetboilerplate.com/Pages/Documents/Navigation
配置模块
和.net框架原生的启动配置相比较，abp有哪些不一样呢？abp框架的模块可以通过IAbpModuleConfigurations接口进行个性化的扩展，这样的话，模块配置更加简单、方便。
示例代码如下：
...
using Abp.Web.Configuration;
...
public override void PreInitialize()
{
Configuration.Modules.AbpWeb().SendAllExceptionsToClients = true;
}
...
</div>
在上面这个例子中，我们通过配置AbpWeb模块，发送异常到客户端。当然了，不是每一个模块都需要这种配置，通常情况下我们需要，是当一个模块需要在多个不同的应用中重复使用，我们才进行这样的配置。
为一个模块创建配置
如下代码，假如我们有一个命名为MyModule的模块，并且这各模块有一些自己的配置。那么我们首先要创建一些类，这些类定义为属性（译者注：属性有自动的get和set访问器。），代表了不同的配置。
public class MyModuleConfig
{
public bool SampleConfig1 { get; set; }
public string SampleConfig2 { get; set; }
}
</div>
接下来，我们通过依赖注入，注册这个类。
IocManager.Register<MyModuleConfig>(); //译者注：在IocManager中注册了一个类，换句话说，我们通过IocManager可以得到这个类MyModuleConfig的实例。至于IOC的原理这里就不在详细说了，总之，就是可以得到一个类的实例。
最后，我们通过创建一个扩展的方法IModuleConfigurations来得到配置的引用。如下代码:
译者注：模块配置是一个静态类，因为我们需要重复使用它。静态方法Mymodule返回的是一个配置接口，参数是ImoduleConfigurations接口。
现在，在其他模块中也可以配置我们自定义的这个MyModule模块了。
Configuration.Modules.MyModule().SampleConfig1 = false; Configuration.Modules.MyModule().SampleConfig2 = "test";</div>
在某种意义上，MyModule需要这些配置，你能注射MyModuleConfig并且可以使用这些值。
public class MyService : ITransientDependency
{
private readonly MyModuleConfig _configuration;
public MyService(MyModuleConfig configuration)
{
_configuration = configuration;
}
public void DoIt()
{
if (_configuration.SampleConfig2 == "test")
{
//...
}
}
}
</div>
这意味着，在abp框架的系统中，所有的模块都可以集中配置。
ABP依赖注入
什么是依赖注入
如果你已经知道依赖注入的概念，构造函数和属性注入模式，你可以跳过这一节。
维基百科说:“依赖注入是一种软件设计模式的一个或多个依赖项注入(或服务)，或通过引用传递，为依赖对象(或客户)和客户端状态的一部分。模式之间建立一个客户的依赖关系的行为，它允许程序设计是松散耦合的，依赖倒置和单一职责原则。它直接对比service locator模式，它允许客户了解他们所使用的系统找到依赖。”。
如果不使用依赖注入技术，很难进行依赖管理、模块化开发和应用程序模块化。
传统方式的问题
在一个应用程序中，类之间相互依赖。假设我们有一个应用程序服务，使用仓储（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);
}
}
</div>
PersonAppService使用PersonRepository插入Person到数据库。这段代码的问题:
PersonAppService通过IPersonRepository调用CreatePerson方法，所以这方法依赖于IPersonRepository，代替了PersonRepository具体类。但PersonAppService（的构造函数）仍然依赖于PersonRepository。组件应该依赖于接口而不是实现。这就是所谓的依赖性倒置原则。
如果PersonAppService创建PersonRepository本身，它成为依赖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);
}
}
</div>
PersonRepositoryFactory是一个静态类，创建并返回一个IPersonRepository。这就是所谓的服务定位器模式。以上依赖问题得到解决，因为PersonAppService不需要创建一个IPersonRepository的实现的对象，这个对象取决于PersonRepositoryFactory的Create方法。但是，仍然存在一些问题：
此时，PersonAppService取决于PersonRepositoryFactory。这是更容易接受，但仍有一个硬依赖（hard-dependency）。
为每个库或每个依赖项乏味的写一个工厂类/方法。
测试性依然不好，由于很难使得PersonAppService使用mock实现IPersonRepository。
解决方案：
有一些最佳实践(模式)用于类依赖。
构造函数注入
重写上面的例子，如下所示:
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);
}
}
</div>
这被称为构造函数注入。现在，PersonAppService不知道哪些类实现IPersonRepository以及如何创建它。谁需要使用PersonAppService，首先创建一个IPersonRepository PersonAppService并将其传递给构造函数，如下所示：