1. Introduction
This document describes a concrete example architecture for .NET/WPF Rich Client Applications. This architecture doesn’t claim to be the preferable solution in every scenario but you might find the one or other part described here useful for your own software systems.
这篇文档描述了一个.NET/WPF Rich Client的架构。这个架构并不适合所有的场景，但是你会发现这里的某些内容对你自己的软件系统有帮助
2. Layered Architecture
Layering is a very useful tool in structuring object-oriented software systems. It helps to organize the types and namespaces into a large-scale structure. The layered architecture defines a few rules to ensure that the structuring is done right. One of the rules says that “lower” layers are low-level and general services, and the “higher” layers are more application specific. This way you are able to divide the software artifacts with related responsibilities together into discrete layers. Another rule says that “higher” layers call types of “lower” layers, but mustn’t vice versa. This rule helps to reduce the coupling and dependencies between the types and so increase the reuse potential, testability and clarity of the software system.
对于OO软件系统来说，分层是一种非常有用的工具。它帮助组织各种类型和命名空间。分层的架构定义了一些规则确保这种结构化能够得到落实。这些规则之一是较低的层提供通常的服务，较高的层更面向更多应用相关的部分。另一个规则是：较高的层调用较低的层，而不是相反。
When a team agrees to use a layered architecture then it has to choose one of the hundreds hardly distinguishable layering schemes found in books about software design and architecture. When you are interested to dig deeper into the different layering schemes then you might start with the book Patterns of Enterprise Application Architectures [Fowler03]. I personally prefer the layering scheme shown in Larman’s book Applying UML and Patterns [Larman04]. Figure 1 shows this layering scheme which I have adapted to reflect the .NET/WPF platform.
当一个团队决定选用分层架构，他们不得不面临要从大量资料中选择一种分层架构。如果你对深入研究不同的分层schema感兴趣，你可以参考《Patterns of Enterprise Application Architectures》。我个人倾向于Larman书里描述的。下图是我的选择
3. Guidelines for a Layered Architecture
1. General vs. Application Specific Types
Separate the types into the different layers. Put the low-level and general service types into the “lower” layers, and the more application specific types into the “higher” layers. This rule is shown by the “more app specific” arrow in Figure 1.
把类型放入不同的层，把一些通用性的放入较低的层，更针对某个应用的放入高一些的层。
2. Dependencies
The characteristic of a layered architecture is that “higher” layers call upon services of “lower” layers, but mustn’t vice versa. This way we avoid circular references between types of different layers and we decrease the number of dependencies. This guideline can be seen by the “dependency” arrow in Figure 1.
分层架构的特点是高层调用底层的服务，而不是相反，以避免循环引用。
3. Applicability
A result of the first and second guideline is that “lower” layers are more reusable than “higher” layers. Figure 1 shows this via the width of the UML packages and the “With implies range of applicability” arrow.
前两条规则的后果是底层的复用性要比高层强。上图中通过UML package的宽度来表示
4. Relaxed Layering
This is also known as layer skipping. Relaxed Layering means that layers are allowed to call layers deeper than the one directly below them. By example a view in the Presentation layer can bind a text box to a property of a business class from the Domain layer.
也称为layer skipping（层可跨越），。Relaxed层意味着一个层可以调用底下若干层，而不局限于下一层，举个例子，表示层中的一个view可以绑定Domain层里的内容
5. White-box reuse
A class is allowed to inherit from a class defined in a lower layer. The same is true for implementing interfaces. However, white-box reuse tightens the coupling between the layers and should be avoided whenever possible. One of the object-oriented design principles in the book Design Pattern [GHJV95] is “Favor object composition over class inheritance”.
可以从底层的类继承，但这种做法不被推荐，可见Design Pattern中的内容
6. Namespaces
The layer name might be a part of the namespace. A common naming scheme for namespaces is: [Company].[Product].[Layer].[SubSystem]
Example: Microsoft.Word.Presentation.Ribbon, Microsoft.Outlook.Domain.AddressBook
层的命名
Tip 1: Avoid the name “Application” inside the namespace because the base class of App.xaml is also named “Application”. Therefore, I use the name “Applications” inside my namespaces to refer to the Application layer.
避免命名为Application
Tip 2: Avoid assemblies that contain types from different layers. When every assembly is associated with just one layer then you gain the advantage that assembly references don’t allow cyclic dependencies. This way the compiler helps you to ensure that the dependencies are from “higher” to “lower” layers. Furthermore, the “internal” access modifier restricts the access to the types inside the same layer. I believe that you should avoid accessing “internal” types or members over layer boundaries.
避免循环引用（没太看明白）
4.Presentation Layer
This layer is responsible for the look and feel of the application. It contains the WPF views, user controls, custom controls, resources, styles, templates, etc. ValueConverters are also common in this layer especially when they convert data from lower layers into WPF objects (e.g. Convert an enum value into an ImageSource). Besides the WPF Framework you might use further technologies for reporting, audio output, speech interface, etc. The code which interacts with these technologies might also be a good candidate for the Presentation layer.
该层负责程序的外观和感受，它包括WPF的view、user control、等等，ValueConverter通常也属于这一层，特别是如果它们负责把底层数据转换为WPF对象。（后面没看懂）
Common Issues
1. Implementing business logic in the Presentation layer instead of the Domain layer.
在表现层实现业务逻辑而不是Domain layer。
2. Implementing the UI workflow in in the Presentation layer instead of the Application layer.
Example: The click event handler of the Options button creates and shows the Options window.
在表现层实现UI工作流程而不是App层，比如某个按钮的点击事件创建并显示一个窗口
3. Implement validation logic in the Presentation layer instead of the Domain layer. The Presentation layer is only responsible to trigger the validation but it is not the place for the validation logic itself. When the validation fails the Presentation layer has to show a user-friendly message.
在表现层实现合法性判断而不是Domain层。表现层应该只负责触发验证，但它并不是进行合法性验证的地方，当合法性验证失败，表现层需要弹出用户友好的消息。
Automated Testing
The Presentation layer is difficult to test because the own code is tightly coupled with the WPF Framework. Two common approaches for testing this layer are:
Automated UI testing with the UI Automation Framework which is well supported by WPF. With this Framework you are able to simulate user interaction and you can track the reaction of your application.
因为表现层的代码和WPF框架绑定在一起，所以非常难于测试。通常有两种方法用于测试该层：
1、UIA
Writing unit tests for your Presentation layer code. In this case you should emulate the behavior of WPF to test your code in a realistic environment. This can be tricky because WPF uses the Dispatcher threading subsystem.
为表现层代码写单元测试代码
5.Application Layer
The Application layer is responsible for the application workflow. A common way to model a static workflow is done with Controller classes. In this case you might have an ApplicationController which is initialized during the start-up sequence. When a program function is triggered the ApplicationController might delegate the process of this function to a use case controller.
应用层负责应用的工作流程。通常用Controller类实现，有一个ApplicationController在启动过程中被初始化。当一个程序的功能被触发，ApplicationController会用use case controller来处理该过程
This layer has the same width as the Presentation layer in Figure 1. The width implies the range of applicability of the layer. Thus, the Application layer is not more reusable than the Presentation layer. This is because the layer is not completely independent of WPF and so it cannot be reused in other application types (e.g. Web Application). Common WPF types found in the Application layer are
应用层的重用性并不比表现层多多少，因为这一层并不完全独立于WPF，所以并不能被其他类型程序使用，比如Web。
ICommand interface - Command Pattern
WeakEventManager class - Weak Events
Dispatcher class - Synchronization with the UI Thread
在应用层，通常有以下几种WPF类型
1、ICommand
2、WeakEventManager
3、Dispatcher
However, even if it’s not totally forbidden to use a type of the WPF Framework in this layer you should avoid using other types as the ones mentioned above.
要尽量避免在这一层使用WPF框架里的类型
Because the layer is weakly coupled with the WPF Framework you are not able to reuse this code with another Presentation technology (e.g. ASP .NET). I don’t believe that this is a real issue because the application workflow often depends on the Presentation technology. By example, desktop applications use mostly different workflows than web applications. In such a case we would have to write two different implementations of the Application layer anyway.
不能在桌面和网页端复用应用层不是大问题，因为流程本身会有区别
The motivation of this layer is to separate the UI from the workflow concerns. The introduction of the Application layer should improve the testability and maintainability of software systems.
这个层的动机是分离UI和workflow，有助于提高可测试性和可维护性
Common Issue
1. Implementing business logic in the Application layer instead of the Domain layer.
在应用层实现业务逻辑而不是Domain层
2.WPF types are implemented or used within the Application layer although they belong to the Presentation layer (e.g. Window, UserControl, Control, Resources, Styles and Templates). This often reduces the testability of this layer.
3. Forbidden namespace dependencies:
System.Windows.Controls
System.Windows.Data
System.Windows.Media
System.Media
System.Waf.Presentation
哪些命名空间不要使用
4. Assembly references you shouldn’t find in this layer:
PresentationFramework
System.Drawing
System.Windows.Forms
Automated Testing
This layer should be designed in a way so that you are able to unit test all of the code. It shouldn’t contain unit testing barriers like the Presentation layer does. If unit testing cannot be done with less effort you might review the design of your Application layer.
这个层应该能够被单元测试。
