本篇我以理论和实践（源代码）两个方面和大家探讨一下我的方案，希望大家多提宝贵意见。

一、软件架构的概念问题，什么是软件的架构?我的理解是：软件的架构包括两个方面的内容，一个是软件的开发架构，一个是软件的部署架构，所谓部署架构就是指部署时的分布式，集群等设计问题；开发架构就是我们平常说的软件分层设计问题，也就是我们今天要谈的问题。

二、何谓分层？分层的方式有几种？分层也就是把一个大的软件解决方案分成多个项目进行开发，分为三种，一种是按照代码的功能层次进行分层，分为数据库访问层，业务逻辑层，UI层等，一种是按照要实现的功能模块进行分层，例如新闻管理层，博客管理层等，第三种就是把前两者结合起来进行分层：先按照代码功能划分好层次，然后再在每一层中分层成各个功能模块。

三、面向接口能够降低各层之间的依赖关系吗？还需要什么？面向接口只是把对对象的直接调用转到了对接口的调用身上，但对接口的调用也需要对象的实例化为前提，因为有对象实例化的存在，所以接口并不能屏蔽掉背后的对象来完成功能；在这种情况下，依赖注入/控制反转等概念应运而生，IOC容器出现了，它能够让对象自动实例化，并管理对象的生存空间。

四、说了这么多，到底应该怎样分？我们不妨从软件的开发过程上来考虑，做软件的都知道我们要进行需求分析，要有需求分析文档，需求分析的任务就是把客户的需求转变为对软件功能的需求，主要内容包括：软件要实现那些功能模块，每个功能模块下包含哪些业务操作，这些业务操作需要哪些页面（或者窗口）支持，这些页面大概都是什么样子的，上面都有什么？有了这些信息，我们就可以开始我们的系统设计了。

我的方案中各个项目的引用关系如下：

说明：

Web：UI层，Asp.net Web应用程序项目，提供用户界面。

UnityConfig：依赖注入配置层，类库项目，对Service层和Business层进行实现配置以提供给Web调用Service层。

Service：为Web层提供服务，类库项目，里面全是接口。

Business：商业逻辑层，通过调用DA数据访问层和Entities层来实现Service层的服务接口。类库项目。

Entities：实体层，类库项目，存放业务实体，贫血型实体。

请注意：在上面的引用关系中，Web层并没有直接引用Business层。

现在假设我们有这样一个需求文档：它只需要实现一个功能模块，就是查找并显示雇员列表。页面形式如图：

首先我们根据需求，先设计服务，因为只有一个功能模块，所以我们只需要一个接口类，再因为只有一个操作功能（查找），所以我们只需要一个服务方法，那么我们在Service层建立一个接口类：IQueryEmployeeService，并添加一个接口方法：QueryEmployee.

根据页面所示，我们这个服务方法需要两个对象参数，一个是查找的条件，一个是查找的结果；这样我们就得到了两个实体类。在Entities建立分别命名为QueryEntry和ListEntry。

代码如下：

namespace Xiaozhuang.Service

{

    public interface IQueryEmployeeService

    {

        /// <summary>

        /// 查询雇员信息

        /// </summary>

        /// <param name="queryentity"></param>

        /// <returns></returns>

        List<ListEntry> QueryEmployee(QueryEntry queryentry);

    }

}

namespace Xiaozhuang.Entities

{

    public class QueryEntry

    {

        public string DepartmentID { get; set; }

        public string EmployeeName { get; set; }

        public string EmployeeAge { get; set; }

        public override string ToString()

        {

            return "DeaprtmentID:" + DepartmentID + "EmployeeName:" + EmployeeName + "EmployeeAge:" + EmployeeAge;

        }

    }

}

namespace Xiaozhuang.Entities

{

    public class ListEntry

    {

        public string EmployeeID { get; set; }

        public string EmployeeName { get; set; }

        public string EmployeeSex { get; set; }

        public int EmployeeAge { get; set; }

        public string DepartmentName { get; set; }

        public string MobilePhone { get; set; }

        public override string ToString()

        {

            return "EmployeeID:" + EmployeeID + "EmployeeName:" + EmployeeName + "EmployeeSex:" + EmployeeSex;

        }

    }

}

请注意，业务实体的设计完全是参照页面而来，对实体字段类型的设计也是参照页面而来，多数都是String类型，因为这个时候并不知道打算在数据库中怎么存储这些数据。

当然在实际的项目中，因为那个部门列表还需要建立部门的业务实体，这里简单其间略去，有了这些业务实体和服务接口，我们就可以设计数据库了，数据库设计完成后，系统设计的工作就完成了。

接下来就是在Business层具体的实现这个查找的方法了：

namespace Xiaozhuang.Business

{

    public class QueryEmployeeBusiness :IQueryEmployeeService

    {

        #region IQueryEmployeeService 成员

        public List<ListEntry> QueryEmployee(QueryEntry queryentry)

        {

            List<ListEntry> listEntry = new List<ListEntry>();

            ListEntry entry1 = new ListEntry() { EmployeeID = "1", EmployeeName = "雇员1", EmployeeSex = "男", DepartmentName = "部门1", EmployeeAge = 30, MobilePhone = "123546789" };

            ListEntry entry2 = new ListEntry() { EmployeeID = "2", EmployeeName = "雇员2", EmployeeSex = "女", DepartmentName = "部门2", EmployeeAge = 29, MobilePhone = "123546789" };

            listEntry.Add(entry1);

            listEntry.Add(entry2);

            return listEntry;

        }

        #endregion

    }

}

此处略去从数据库查询的方法，可以用Linq to sql 实现或者其他Orm工具。

接下来配置一下我们的UnityConfig层，就可以在Web层访问这个查找雇员的服务了。

namespace Xiaozhuang.UnityConfig

{

        public interface IContainerAccessor

        {

            IUnityContainer Container { get; }

        }

        public class UnityContainerConfig

        {

            public IUnityContainer GetIUnityContainer()

            {

                IUnityContainer container = new UnityContainer();

                container.RegisterType<IQueryEmployeeService, QueryEmployeeBusiness>();

                return container;

            }

        }

}

当然你也可以把这个配置写到Web。Config中。

接下来的问题就是怎样在Web层调用这个服务的问题了，这个问题其实还是比较复杂的，文章太长了大家都看烦了，我将在下次再详细说说这个问题。

   目前在.Net下实现AOP的方式分为两大类：一是采用动态代理技术，利用截取消息的方式，对该消息进行装饰，以取代或修饰原有对象行为的执行；二是采用静态织入的方式，引入特定的语法创建“方面”，从而使得编译器可以在编译期间织入有关“方面”的代码。动态代理实现方式利用.Net的Attribute和.Net Remoting的代理技术，对对象执行期间的上下文消息进行截取，并以消息传递的方式执行，从而可以在执行期间加入相关处理逻辑实现面向方面的功能（请参考：http://www.cnblogs.com/wayfarer/articles/256909.html）；而静态织入的方式实现一般是要依靠一些第三方框架提供特定的语法，例如PostSharp，它的实现方式是采用 MSIL Injection和MSBuild Task在编译时置入方面的代码，从而实现AOP。

PostSharp和基于 Dynamic Proxy 方式做个比较。

1、由于采用 MSIL Injection，因此静态代码注入的执行效率要高于使用 Reflection Emit。
2、使用 MSBuild Task，使得开发人员可以像使用编译器内置 Attribute 那样使用 AOP。
3、可以拦截任意方法，而 Dynamic Proxy 方式的 AOP 往往采取继承方式来拦截 Virtual 方法。
4、拥有更多的控制权。包括中断执行流程，修改参数和返回值等等。
5、还可以拦截 Field Access、Exception 等操作。
6、无需将对象创建代码改成 "new proxy()"，更加透明。
7、可以使用通配符进行多重拦截匹配。
8、静态注入带来的问题更多的是注入代码的质量和调试复杂度。

看了以上比较，让我对PostSharp佩服的五体投地，决定研究一下，既然执行效率要要比动态代理的方式高，我就想知道到底高多少？好让我忏悔以前使用动态代理方式的错误，并一心转到PostSharp上来。

为此我写了一个Console程序，用StopWatch来查看两种AOP实现方式的耗时是多少，相差多少？这个Console程序在此下载（vs2008），本来我以为肯定是PostSharp耗时少，但测试的结果大大出乎我的意料，如图：

其中用dotNet原生的动态代理方式耗时为14毫秒，而Postsharp实现方式的的耗时为79毫秒，最下面那个0毫秒的是无AOP时该方法的执行时间。如果把PostSharp实现放在动态代理实现的前面执行，PostSharp的耗时更多，而DotNet动态代理的方式耗时更少，我想这可能是因为dotnet运行环境对方法的运行参数进行了缓存所致，第二次运行比第一次运行更快一点。

用Reflector查看Postsharp实现方式方法的源代码：

public int MyTestMethod(int p1, int p2, out int p3)
{
// This item is obfuscated and can not be translated.
int ~returnValue~4;
object[] ~arguments~6;
MethodExecutionEventArgs ~laosEventArgs~7;
try
{
object[] objArray1 = new object[3];
objArray1[0] = p1;
objArray1[1] = p2;
~arguments~6 = objArray1;
~laosEventArgs~7 = new MethodExecutionEventArgs(methodof(PostSharpTestClass.MyTestMethod, PostSharpTestClass), this, ~arguments~6);
~PostSharp~Laos~Implementation.PostSharpPerformanceTestAttribute~1.OnEntry(~laosEventArgs~7);
if (~laosEventArgs~7.get_FlowBehavior() == 3)
{
~returnValue~4 = (int) ~laosEventArgs~7.get_ReturnValue();
~arguments~6[2] = (int) p3;
return ~returnValue~4;
}
int tempint = 0;
for (int i = 1; i <= 100; i++)
{
tempint += i;
}
p3 = tempint;
int CS$1$0000 = p1 + p2;
~returnValue~4 = CS$1$0000;
~arguments~6[2] = (int) p3;
~laosEventArgs~7.set_ReturnValue(~returnValue~4);
~PostSharp~Laos~Implementation.PostSharpPerformanceTestAttribute~1.OnSuccess(~laosEventArgs~7);
p3 = (int) ~arguments~6[2];
~returnValue~4 = (int) ~laosEventArgs~7.get_ReturnValue();
}
catch (Exception ~exception~5)
{
~laosEventArgs~7.set_Exception(~exception~5);
~arguments~6[2] = (int) p3;
~PostSharp~Laos~Implementation.PostSharpPerformanceTestAttribute~1.OnException(~laosEventArgs~7);
p3 = (int) ~arguments~6[2];
switch (~laosEventArgs~7.get_FlowBehavior())
{
case 1:
return ~returnValue~4;
case 3:
return (int) ~laosEventArgs~7.get_ReturnValue();
}
throw;
}
finally
{
~arguments~6[2] = (int) p3;
~laosEventArgs~7.set_ReturnValue(~returnValue~4);
~PostSharp~Laos~Implementation.PostSharpPerformanceTestAttribute~1.OnExit(~laosEventArgs~7);
p3 = (int) ~arguments~6[2];
~returnValue~4 = (int) ~laosEventArgs~7.get_ReturnValue();
}
return ~returnValue~4;
}

给我的感觉是：好长，好繁。我认为之所以PostSharp的耗时更长的原因就在这里，它把这个方法搞复杂了，

所以耗时就长了，但DotNet原生的动态代理方式并不会这样，但对性能也有不小的影响。

综上所述：我认为我们在使用AOP技术进行开发时，除非很有必要用到PostSharp提供的那么多功能，

要是只是实现权限验证，日志、异常捕获等，用DotNet原生的动态代理实现就可以了。

补充：我让两种实现方式各运行1000次来计算各自的总共耗时，测试的结果是：dotnet：250-350 ；

PostSharp：1250-1300；而且在各自的1000次执行中，大多数次数执行耗时为0毫秒，

而各自的第一次执行耗时与前面测试耗时基本相同，分别为14和79左右，

随后继续以下次数执行，基本都为0毫秒，随后的某次执行会耗时大于0毫秒，

但dotnet实现方式的大于0毫秒的次数比PostSharp出现的次数晚，

DotNet在第80次左右出现一次大于0毫秒的情况,而PostSharp在第25次左右的地方出现一次大于0毫秒的情况。

WCF支持多种认证技术，例如Windowns认证、X509证书、Issued Tokens、用户名密码认证等，在跨Windows域分布的系统中，用户名密码认证还是比较常用的，要实现用户名密码认证，就必须需要X509证书，为什么呢？因为我们需要X509证书这种非对称密钥技术来实现WCF在Message传递过程中的加密和解密，要不然用户名和密码就得在网络上明文传递！详细说明就是客户端把用户名和密码用公钥加密后传递给服务器端，服务器端再用自己的私钥来解密，然后传递给相应的验证程序来实现身份验证。

当然，做个测试程序就没有必要去申请一个X509数字签名证书了，微软提供了一个makecert.exe的命令专门用来生成测试使用的X509证书的，那我们就来建立一个测试用的证书，在cmd下输入以下命令：

makecert.exe -sr LocalMachine -ss My -a sha1 -n CN=MyServerCert -sky exchange –pe

这个命令的意思就是创建一个测试的X509证书，这个证书放在存储位置为'Localmachine'的'My'这个文件夹下，证书主题名字叫'MyServerCert'，需要更多关于makecert命令的信息请参考MSDN。

证书建立好了，我们就可以编写代码了，在VS2008下建立一个解决方案并在上面建立两个Web项目，一个是'Asp.net Web 应用程序'（客户端），一个是'WCF服务应用程序'（服务器端），我们先来编写服务器端代码，首先我们要编写自己的用户名密码认证逻辑，先要在WCF项目上添加引用'System.IdentityModel'然后我们建立一个新的类文件并继承自'System.IdentityModel.Selectors.UserNamePasswordValidator'，然后我们重写里面的'Validate'方法来实现用户名密码认证逻辑。代码如下；

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.IdentityModel.Selectors;

using System.IdentityModel.Tokens;

namespace ServerWcfService.CustomValidators

{

public class MyCustomValidator : UserNamePasswordValidator

{

/// <summary>

/// Validates the user name and password combination.

/// </summary>

/// <param name="userName">The user name.</param>

/// <param name="password">The password.</param>

public override void Validate(string userName, string password)

{

// validate arguments

if (string.IsNullOrEmpty(userName))

throw new ArgumentNullException("userName");

if (string.IsNullOrEmpty(password))

throw new ArgumentNullException("password");

// check if the user is not xiaozhuang

if (userName != "xiaozhuang" || password != "123456")

throw new SecurityTokenException("用户名或者密码错误！");

}

}

}

上面只是一个简单的验证，实际应用中用户名和密码一般都保存在数据库中，如果验证不通过就抛出一个'SecurityTokenException'类型的异常；下一步我们需要配置一下服务端的webConfig文件，我的WebConfig文件Servicemodel配置节如下：

<system.serviceModel>

        <bindings>

            <wsHttpBinding>

                <binding name="mySecureBinding">

                    <security mode="Message">

                        <message clientCredentialType="UserName"/>

                    </security>

                </binding>

            </wsHttpBinding>

        </bindings>

        <services>

            <service behaviorConfiguration="ServerWcfService.Services.MySimpleServiceBehavior" name="ServerWcfService.Services.MySimpleService">

                <endpoint address="" binding="wsHttpBinding" contract="ServerWcfService.ServiceContracts.IMySimpleService" bindingConfiguration="mySecureBinding">

                    <identity>

                        <dns value="MyServerCert"/>

                    </identity>

                </endpoint>

                <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>

            </service>

        </services>

        <behaviors>

            <serviceBehaviors>

                <behavior name="ServerWcfService.Services.MySimpleServiceBehavior">

                    <serviceMetadata httpGetEnabled="true"/>

                    <serviceDebug includeExceptionDetailInFaults="false"/>

                    <serviceCredentials>

                        <serviceCertificate findValue="MyServerCert" x509FindType="FindBySubjectName" storeLocation="LocalMachine" storeName="My"/>

                        <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="ServerWcfService.CustomValidators.MyCustomValidator,ServerWcfService"/>

                    </serviceCredentials>

                </behavior>

            </serviceBehaviors>

        </behaviors>

    </system.serviceModel>

加粗的那些是我加上去的或者在默认上修改了的。Bindings节指定了客户端提供的认证类型为'username'并在endpoint节中指定bianding配置。在dns节中修改原来的localmachine为MyServerCert，当然你也可以修改为别的，这取决于你的证书主题名称是什么。也就是上面命令中的CN=MyServerCert，接下来我们加入在serviceCredentials配置节，并在里面配置两个小节，ServiceCertificate节中指定了我们的X509证书的位置，以用来加解密message，usernameAuthentication节中指定了我们自己的用户名密码验证逻辑。

Sorry，忘了一件事情，就是写一个测试的服务契约并实现，写法上和无认证的写法一样，如下ServerWcfService.ServiceContracts.IMySimpleService：

[OperationContract]

string PrintMessage(string message);

这样，服务端的代码编写和配置就完成了，生成项目测试一下，页面显示服务已生成成功。

接下来我们开始编写客户端代码，先在客户端引用刚才生成的WCF服务，然后编写客户端代码如下：

protected void btnPrint_Click(object sender, EventArgs e)

{

TestWCFService.MySimpleServiceClient client = new ClientWeb.TestWCFService.MySimpleServiceClient();

client.ClientCredentials.UserName.UserName = "xiaozhuang";

client.ClientCredentials.UserName.Password = "123456";

lbMessage.Text = client.PrintMessage(txtMessage.Text);

}

如果你有一个真正的X509证书，那么现在的代码就可以正常运行了。但是很不幸，我们的证书是测试用的，我们运行的时候出错：'X.509 certificate CN=MyServerCert 链生成失败。所使用的证书具有无法验证的信任链。请替换该证书或更改 certificateValidationMode。已处理证书链，但是在不受信任提供程序信任的根证书中终止'，WCF无法验证测试证书的信任链，那我们要做的就是绕过这个信任验证，具体做法如下：

先要在Asp.net Web应用程序项目上添加引用'System.IdentityModel'然后我们建立一个新的类文件并继承自'System.IdentityModel.Selectors.X509CertificateValidator'，然后我们重写里面的'Validate'方法来实现我们自己的X509认证逻辑，代码如下：

using System;

using System.Configuration;

using System.IdentityModel.Selectors;

using System.IdentityModel.Tokens;

using System.Security.Cryptography.X509Certificates;

namespace ClientWeb.CustomX509Validator

{

    /// <summary>

    /// Implements the validator for X509 certificates.

    /// </summary>

    public class MyX509Validator: X509CertificateValidator

    {

        /// <summary>

        /// Validates a certificate.

        /// </summary>

        /// <param name="certificate">The certificate the validate.</param>

        public override void Validate(X509Certificate2 certificate)

        {

            // validate argument

            if (certificate == null)

                throw new ArgumentNullException("X509认证证书为空！");

            // check if the name of the certifcate matches

            if (certificate.SubjectName.Name != ConfigurationManager.AppSettings["CertName"])

                throw new SecurityTokenValidationException("Certificated was not issued by thrusted issuer");

        }

    }

}

你可以把Validate方法里面留空让所有的认证都通过，也可以自己定义认证逻辑，如果认证失败，就抛出'SecurityTokenValidationException'的异常，然后我们配置一下客户端的webconfig让它使用我们自己的X509认证，增加以下的配置节，并在'endpoint'节中指定behaviorConfiguration="myClientBehavior"。

<behaviors>

            <endpointBehaviors>

                <behavior name="myClientBehavior">

                    <clientCredentials>

                        <serviceCertificate>

                            <authentication certificateValidationMode="Custom" customCertificateValidatorType="ClientWeb.CustomX509Validator.MyX509Validator,ClientWeb" />

                        </serviceCertificate>

                    </clientCredentials>

                </behavior>

            </endpointBehaviors>

        </behaviors>

OK，客户端代码和配置完成，现在你可以运行自己的程序了，运行界面如下：如果需要源代码在这里下载.

1、只有 BasicHttpBinding、NetTcpBinding 和 NetNamedPipeBinding 支持传送流数据。

2、 流数据类型必须是可序列化的 Stream 或 MemoryStream。

3、 传递时消息体(Message Body)中不能包含其他数据。

4、TransferMode的限制和MaxReceivedMessageSize的限制等。

下面具体实现：新建一个WCFService，接口文件的代码如下：

[ServiceContract]
    public interface IUpLoadService
    {
        [OperationContract(Action = "UploadFile", IsOneWay = true)]
        void UploadFile(FileUploadMessage request);
    }


    [MessageContract]
    public class FileUploadMessage
    {
        [MessageHeader(MustUnderstand = true)]
        public string SavePath;

        [MessageHeader(MustUnderstand = true)]
        public string FileName;

        [MessageBodyMember(Order = 1)]
        public Stream FileData;

    }

定义FileUploadMessage类的目的是因为第三个限制，要不然文件名和存放路径就没办法传递给WCF了，根据第二个限制，文件数据是用System.IO.Stream来传递的

接口方法只有一个，就是上传文件，注意方法参数是FileUploadMessage

接口实现类文件的代码如下：

 public class UpLoadService : IUpLoadService
    {
        public void UploadFile(FileUploadMessage request)
        {
            string uploadFolder = @"C:\kkk\";
            string savaPath = request.SavePath;
            string dateString = DateTime.Now.ToShortDateString() + @"\";
            string fileName = request.FileName;
            Stream sourceStream = request.FileData;
            FileStream targetStream = null;
           
            if (!sourceStream.CanRead)
            {
                throw new Exception("数据流不可读!");
            }
            if (savaPath == null) savaPath = @"Photo\";
            if (!savaPath.EndsWith("\\")) savaPath += "\\";

            uploadFolder = uploadFolder + savaPath + dateString;
            if (!Directory.Exists(uploadFolder))
            {
                Directory.CreateDirectory(uploadFolder);
            }

            string filePath = Path.Combine(uploadFolder, fileName);
            using (targetStream = new FileStream(filePath, FileMode.Create, FileAccess.Write, FileShare.None))
            {
                //read from the input stream in 4K chunks
                //and save to output stream
                const int bufferLen = 4096;
                byte[] buffer = new byte[bufferLen];
                int count = 0;
                while ((count = sourceStream.Read(buffer, 0, bufferLen)) > 0)
                {
                    targetStream.Write(buffer, 0, count);
                }
                targetStream.Close();
                sourceStream.Close();
            }
        }

    }

实现的功能是到指定目录下按照日期进行目录划分，然后以传过来的文件名保存文件。

这篇文章最主要的地方就是下面的Web.Config配置：

<system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding name="FileTransferServicesBinding" maxReceivedMessageSize="9223372036854775807"
          messageEncoding="Mtom" transferMode="Streamed" sendTimeout="00:10:00" />
          </basicHttpBinding>
    </bindings>
    <services>
      <service behaviorConfiguration="UploadWcfService.UpLoadServiceBehavior"
        name="UploadWcfService.UpLoadService">
        <endpoint address="" binding="basicHttpBinding" bindingConfiguration="FileTransferServicesBinding" contract="UploadWcfService.IUpLoadService">
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="UploadWcfService.UpLoadServiceBehavior">
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="false" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

配置要遵循上面的第一条和第四条限制，因为默认.net只能传4M的文件，所以要在
<System.Web>配置节下面加上<httpRuntimemaxRequestLength="2097151" />

这样WCFService就完成了，新建一个Console项目或者Web项目测试一下。要注意的
是Client端的配置必须要和服务端一样，实例程序在这里下载。

第一节：ExtJS调用WCF系列-----实现JSON传递

第二节：ExtJS调用WCF系列-----分页排序列表实现

第三节：ExtJS调用WCF系列-----添加，修改，删除