The Onion Architecture（洋葱架构） part2

In part 1, I introduced an architectural pattern that I have named "Onion Architecture".  The object-oriented design concepts are not new, but I'm pulling together a lot of techniques and conventions into a single pattern and giving it a name.  My hope is that the industry can use this name to communicate the architectural approach where appropriate.

在第1部分中，我介绍了一种我称之为“洋葱架构”的架构模式。面向对象设计的概念不是新鲜事物，但是我将许多技术和约定集成到一个单一的模式中，并为之命名。我希望业界可以在合适的时候使用这个名称来交流架构方法。

Part 2:  Practical example:

第二部分：实例

CodeCampServer uses the Onion Architecture.  If you are looking for a full, working application as an example, please have a look.  The practical example I put before you is taken directly from CodeCampServer.  It is a narrow, vertical slice of an example.  I'm keeping the scope small as to be digestible.  I'll start with a diagram so you can understand where all the code resides within the layers of the onion. 

Codecampserver使用了洋葱结构。如果您正在寻找一个完整的，可运行的应用程序作为一个例子，请看一看Codecampserver。放在你面前的实例直接来自于Codecampserver。这是一个范围很小，垂直切片的例子。我把范围缩小以便于容易消化。我将从图开始，这样您就可以理解洋葱各层中所有代码的位置。

CodeCampServer uses the ASP.NET MVC Framework, so SpeakerController is part of the user interface.  This controller is coupled to the ASP.NET MVC Framework, and there is no getting around that.  SpeakerController depends on IConferenceRepository and IUserSession (and IClock, but we'll omit that).  The controller only depends on interfaces, which are defined in the application core.  Remember that all dependencies are toward the center. 

Codecampserver采用ASP.NET的MVC框架，所以SpeakerController是用户接口的一部分。此控制器耦合到ASP.NET的MVC框架，对此不用避讳。SpeakerController依赖于IConferenceRepository和IUserSession（和IClock，但我们可以省略）。控制器只依赖于应用内核中定义的接口。记住所有依赖项都指向中心。

Turn your attention to the ConferenceRepository and UserSession classes.  Notice that they are in layers outside of the application core, and they depend on the interfaces as well, so that they can implement them.  These two classes each implement an interface closer to the center than itself.  At runtime, our Inversion of Controlcontainer will look at its registry and construct the proper classes to satisfy the constructor dependencies of SpeakerController, which is the following:

把你的注意力转向ConferenceRepository和UserSession 类。请注意，它们位于应用内核之外的层中，它们也依赖于接口，以至于能够实现它们。这两个类都实现了一个比它们自己更靠近中心的接口。在运行时，我们的IoC容器会看它的注册并且构造合适的类以满足SpeakerController构造函数的依赖，如下所示：

public SpeakerController(IConferenceRepository conferenceRepository,
                         IUserSession userSession, IClock clock)
    : base(userSession)
{
    _conferenceRepository = conferenceRepository;
    _clock = clock;
    _userSession = userSession;
}

At runtime, the IoC container will resolve the classes that implement interfaces and pass them into the SpeakerController constructor.  At this point in time, the SpeakerController can do its job. 

在运行时，IoC容器将构造出实现接口的类并将它们传递到SpeakerController构造函数。在这个时间点，SpeakerController能够执行。

Based on the rules of the Onion Architecture, the SpeakerController _could_ use UserSession directly since it's in the same layer, but it cannot use ConferenceRepository directly.  It must rely on something external passing in an instance of IConferenceRepository.  This pattern is used throughout, and the IoC container makes this process seamless.

基于洋葱架构的规则，SpeakerController 可直接使用使用UserSession ，因为它位于同一层，但它不能直接使用ConferenceRepository 。它必须依靠外部的东西传递到IConferenceRepository的实例内。这个模式贯穿始终，IoC容器使这个过程无缝衔接。

At the end of this series, I plan on publishing a full working system that adheres to the Onion Architecture pattern.  The systems we build for clients use this approach, but I'm not at liberty to discuss that code, so I will craft a reference application for those of you who prefer a concrete Visual Studio solution to digest.

在本系列的最后，我计划发布一个完整的基于洋葱架构模式的工作系统。我们在为客户构建的系统中使用了这种方法，但我不能随意讨论那些代码，所以我将为那些喜欢使用具体的Visual Studio解决方案的人编写一个可参考的应用程序。