C#中實現(xiàn)Fluent Interface的三種方法

更新時間：2015年03月31日 09:23:54 投稿：junjie

這篇文章主要介紹了C#中實現(xiàn)Fluent Interface的三種方法,本文講解了Fluent Interface的簡單實現(xiàn)、使用裝飾器模式和擴展方法實現(xiàn)Fluent Interface等3種實現(xiàn)方法,需要的朋友可以參考下

背景知識

Fluent Interface是一種通過連續(xù)的方法調(diào)用以完成特定邏輯處理的API實現(xiàn)方式，在代碼中引入Fluent Interface不僅能夠提高開發(fā)效率，而且在提高代碼可讀性上也有很大的幫助。從C# 3.0開始，隨著擴展方法的引入，F(xiàn)luent Interface也更多地被開發(fā)人員熟悉和使用。例如，當(dāng)我們希望從一個整數(shù)列表中找出所有的偶數(shù)，并將這些偶數(shù)通過降序排列的方式添加到另一個列表中時，可以使用下面的代碼：

復(fù)制代碼代碼如下:

i.Where(p => p % 2 == 0)

    .OrderByDescending(q => q)

    .ToList()

    .ForEach(r => result.Add(r));

這段代碼不僅看起來非常清晰，而且在編寫的時候也更符合人腦的思維方式，通過這些連續(xù)的方法調(diào)用，我們首先從列表i中尋找所有的偶數(shù)，然后對這些偶數(shù)進行排序并將排序后的值逐個添加到result列表中。

在實際應(yīng)用中，F(xiàn)luent Interface不僅僅是使用在類似上面的查詢邏輯上，而它更多地是被應(yīng)用開發(fā)框架的配置功能所使用，比如在Entity Framework Code First中可以使用Fluent API對實體（Entity）和模型（Model）進行配置，此外還有流行的ORM框架NHibernate以及企業(yè)服務(wù)總線框架NServiceBus等等，都提供了類似的Fluent API，以簡化框架的配置過程。這些API都是Fluent Interface的具體實現(xiàn)。由于Fluent Interface的方法鏈中各方法的名稱都具有很強的描述性，而且具有單一職責(zé)的特點，所以Fluent Interface也可以看成是完成某一領(lǐng)域特定任務(wù)的“領(lǐng)域特定語言（Domain Specific Language）”，比如在上面的例子中，F(xiàn)luent Interface被用于查詢領(lǐng)域，而在Entity Framework、NHiberante和NServiceBus等框架中，它又被用于框架的配置領(lǐng)域。

接下來，讓我們首先看一下Fluent Interface的簡單實現(xiàn)方式，并簡要地討論一下這種實現(xiàn)方式的優(yōu)缺點，再來了解一下一種使用裝飾器（Decorator）模式和擴展接口的實現(xiàn)方式。

Fluent Interface的簡單實現(xiàn)

Fluent Interface的一種簡單實現(xiàn)就是在類型的每個方法中對傳入?yún)?shù)進行處理，然后返回該類型本身的實例，因此，當(dāng)該類型的某個方法被調(diào)用后，進而還可以連續(xù)地直接調(diào)用其它的方法而無需在調(diào)用時指定該類型的實例。現(xiàn)假設(shè)我們需要實現(xiàn)某個服務(wù)接口IService，在這個接口中，要用到一個提供緩存功能的接口ICache以及一個提供日志記錄的接口ILogger，為了讓IService的實例能夠以Fluent Interface的方式指定自己所需要的ICache接口和ILogger接口的實例，我們可以這樣定義IService接口：

復(fù)制代碼代碼如下:

public interface IService

{

    ICache Cache { get; }

    ILogger Logger { get; }

    IService UseCache(ICache cache); // return ‘this' in implemented classes

    IService UseLogger(ILogger logger); // return ‘this' in implemented classes

}

于是，對IService實例的配置就變得非常簡單，比如：

復(fù)制代碼代碼如下:

IService aService = new Service();

aService.UseCache(new AppfabricCache()).UseLogger(new ConsoleLogger());

這是最簡單的Fluent Interface的實現(xiàn)方式，對于一些簡單的應(yīng)用場景，使用這種簡單快捷的方式的確是個不錯的選擇，但在體驗著這種便捷的同時，我們或許還需要進行更進一步的思考：

1.直接定義在IService接口上的UseCache和UseLogger方法會破壞IService本身的單一職責(zé)性，而這又是與軟件設(shè)計的思想是沖突的。到底是用哪種緩存服務(wù)和哪種日志服務(wù)，這并不是IService需要考慮的問題。當(dāng)然，C#的擴展方法可以很方便地把UseCache和UseLogger等方法從IService接口中剝離出去，但更合理的做法是，使用工廠來創(chuàng)建IService的實例，而創(chuàng)建實例的依據(jù)（上下文）則應(yīng)該由其它的配置信息來源提供
2.無法保證上下文的正確性。在上面的例子中，這個問題并不明顯，先調(diào)用UseCache還是先調(diào)用UseLogger并不會給結(jié)果造成任何影響。但在某些應(yīng)用場景中，設(shè)置的對象之間本身就存在一定的依賴關(guān)系，比如在Entity Framework Code First的Entity Type Configuration中，只有當(dāng)所配置的屬性是字符串的前提下，才能夠進一步對該屬性的最大長度、是否是Unicode等選項進行設(shè)置，否則Fluent Interface將不會提供類似的方法調(diào)用。顯然目前這個簡單的實現(xiàn)并不能滿足這種需求
3.需要首先創(chuàng)建IService類型的實例，然后才能使用UseCache和UseLogger等方法對其進行設(shè)置，如果在實例的創(chuàng)建過程中存在對ICache或者ILogger的依賴的話（比如在構(gòu)造函數(shù)中希望能夠使用ILogger的實例寫一些日志信息等），那么實現(xiàn)起來就會比較困難了

鑒于以上三點分析，當(dāng)需要在應(yīng)用程序或開發(fā)框架中更為合理地引入Fluent Interface時，上述簡單的實現(xiàn)方式就無法滿足所有需求了。為此，我采用裝飾器模式，并結(jié)合C#的擴展方法特性來實現(xiàn)Fluent Interface，這種方式不僅能夠解決上面的三種問題，而且面向?qū)ο蟮脑O(shè)計會使Fluent Interface的擴展變得更加簡單。

使用裝飾器模式和擴展方法實現(xiàn)Fluent Interface

仍然以上文中的IService接口為例，通過分析我們可以得到兩個啟示：首先，對于IService的實例究竟應(yīng)該是采用哪種緩存機制以及哪種日志記錄機制，這就是一種對IService的實例進行配置的過程；其次，這種配置過程就相當(dāng)于在每個配置階段逐漸地向已有的配置信息上添加新的信息，比如最開始創(chuàng)建一個空的配置信息，在第一階段確定了所選用的緩存機制時，就會在這個空的配置信息基礎(chǔ)上添加與緩存相關(guān)的配置信息，而在第二階段確定了所選用的日志記錄機制時，又會在前一階段獲得的配置信息基礎(chǔ)上再添加與日志記錄相關(guān)的配置信息，這個過程正好是裝飾器模式的一種應(yīng)用場景。最后一步就非常簡單了，程序只需要根據(jù)最終得到的配置信息初始化IService接口的實例即可。為了簡化實現(xiàn)過程，我選擇Microsoft Patterns & Practices Unity Application Block的IoC容器來實現(xiàn)這個配置信息的管理機制。選用Unity IoC容器的好處是，對接口及其實現(xiàn)類型的注冊并沒有先后順序的要求，IoC容器會自動分析類型之間的依賴關(guān)系并對類型進行注冊。事實上在很多應(yīng)用程序開發(fā)框架中，也是用這種方式在框架的配置部分實現(xiàn)Fluent Interface的。

裝飾器模式的引入

首先我們引入“配置器”的概念，配置器的作用就是對IService實例初始化過程中的某個方面（例如緩存或者日志）進行配置，它會向調(diào)用者返回一個Unity IoC容器的實例，以便調(diào)用方能夠在該配置的基礎(chǔ)上進行其它方面的配置操作（為了簡化起見，下文中所描述的“配置”僅表示選擇某種特定類型的實現(xiàn)，而不包含其它額外的配置內(nèi)容）。我們可以使用如下接口對配置器進行定義：

復(fù)制代碼代碼如下:

public interface IConfigurator

{

    IUnityContainer Configure();

}

為了實現(xiàn)的方便，我們還將引入一個抽象類，該抽象類實現(xiàn)了IConfigurator接口，并將其中的Configure方法標(biāo)識為抽象方法。于是，對于任何一種配置器而言，它只需要繼承于該抽象類，并且重載Configure方法即可實現(xiàn)配置邏輯。該抽象類的定義如下：

復(fù)制代碼代碼如下:

public abstract class Configurator : IConfigurator

{

    readonly IConfigurator context;

    public Configurator(IConfigurator context)

    {

        this.context = context;

    }

    protected IConfigurator Context

    {

        get

        {

            return this.context;

        }

    }

    public abstract IUnityContainer Configure();

}

接下來就是針對不同的配置環(huán)節(jié)實現(xiàn)各自的配置器了。我們以緩存機制的配置為例，簡要介紹一下“緩存配置器”的實現(xiàn)方式。

先定義一個名為ICacheConfigurator的接口，該接口實現(xiàn)了IConfigurator的接口，但它是一個空接口，并不包含任何屬性、事件或方法的接口定義。引入這個接口的目的就是要在接下來的擴展方法定義中能夠?qū)崿F(xiàn)面向該接口的方法擴展，于是上文中討論的第二個問題就能引刃而解，這將在接下來的“擴展方法的引入”部分進行討論。事實上在很多成熟的應(yīng)用程序和框架中也有類似的設(shè)計，比如將接口用作泛型約束類型等。因此，ICacheConfigurator的實現(xiàn)代碼非常簡單：

復(fù)制代碼代碼如下:

public interface ICacheConfigurator : IConfigurator

{

}

而作為“緩存配置器”而言，它只需要繼承于Configurator類并實現(xiàn)ICacheConfigurator接口就可以了，代碼如下：

復(fù)制代碼代碼如下:

public class CacheConfigurator<TCache> : Configurator, 

    ICacheConfigurator

    where TCache : ICache

{

    public CacheConfigurator(IConfigurator configurator)

        : base(configurator)

    {

    }

    public override IUnityContainer Configure()

    {

        var container = this.Context.Configure();

        container.RegisterType<ICache, TCache>();

        return container;

    }

}

從上面的代碼中可以看到，TCache約束于ICache接口類型，而在Configure方法中，首先調(diào)用配置上下文（也就是配置器本身所包含的上一層配置器實例）的Configure方法，同時獲得已配置的Unity IoC容器實例container，之后在container上繼續(xù)調(diào)用RegisterType方法，將給定的緩存機制實現(xiàn)類型注冊到container中，最后將container返回給調(diào)用者。

整個配置器部分的實現(xiàn)，可以用下面的類圖進行總結(jié)：

擴展方法的引入

前面已經(jīng)提到過，擴展方法可以將職責(zé)無關(guān)的方法定義從類型中移出，并在一個靜態(tài)類中進行集中實現(xiàn)。在目前的這個例子中，擴展方法還能夠幫助我們將類型繼承的層次結(jié)構(gòu)“扁平化”，使得Fluent Interface中各方法的銜接邏輯變得更加清晰。仍然以緩存配置部分為例，假設(shè)我們希望在獲得了服務(wù)的配置之后，能夠接著對緩存機制進行配置，在完成了緩存機制的配置后，才能開始對日志記錄機制進行配置，那么我們就可以定義擴展方法如下：

復(fù)制代碼代碼如下:

public static ICacheConfigurator WithDictionaryCache(this IServiceConfigurator configurator)

{

    return new CacheConfigurator<DictionaryCache>(configurator);

}

public static ILoggerConfigurator WithConsoleLogger(this ICacheConfigurator configurator)

{

    return new LoggerConfigurator<ConsoleLogger>(configurator);

}

上面的WithDictionaryCache方法表示需要在Service的配置上采用基于字典的緩存機制，而WithConsoleLogger則表示在緩存配置的基礎(chǔ)上，還需要選用控制臺作為日志記錄機制。

從上面的代碼中我們還能了解到，擴展方法還能夠很直觀地定義各種配置之間的先后順序，更改起來也非常方便。例如，如果緩存機制和日志記錄機制的配置沒有一個前后關(guān)系的話，那么我們可以將IServiceConfigurator作為WithConsoleLogger的第一個參數(shù)類型，而無需去修改代碼中的其它任何部分。

接下來要做的，就是設(shè)計一個工廠類，使其能夠根據(jù)我們的配置信息創(chuàng)建一個新的IService實例。

工廠類的實現(xiàn)

工廠類的實現(xiàn)就非常簡單了，同樣使用擴展方法，對IConfigurator類型進行擴展，在獲得了Unity IoC容器的實例之后，只需要調(diào)用Resolve方法直接返回IService類型的實現(xiàn)類型就可以了。Resolve方法的使用，直接解決了上文中提到的第三個問題。工廠類的代碼如下：

復(fù)制代碼代碼如下:

public static class ServiceFactory

{

    public static IToConfigConfigurator ToConfig()

    {

        return new ToConfigConfigurator();

    }

    public static IService Create()

    {

        return ToConfig().Service().Create();

    }

    public static IService Create(this IConfigurator configurator)

    {

        var container = configurator.Configure();

        if (!container.IsRegistered<ICache>())

            container.RegisterType<ICache, DictionaryCache>();

        if (!container.IsRegistered<ILogger>())

            container.RegisterType<ILogger, ConsoleLogger>();

        if (!container.IsRegistered<IService>())

            container.RegisterType<IService, Service>();

        return container.Resolve<IService>();

    }

}

測試

創(chuàng)建一個測試項目以便對我們所做的工作進行測試，比如下面的測試方法將會對IService的實現(xiàn)所采用的緩存機制類型和日志記錄機制類型進行測試：

復(fù)制代碼代碼如下:

[TestMethod]

public void UseAppfabricCacheAndDatabaseLoggerTest()

{

    var service = ServiceFactory

        .ToConfig()

        .Service()

        .WithAppfabricCache()

        .WithDatabaseLogger()

        .Create();

    Assert.IsInstanceOfType(service.Cache, typeof(AppfabricCache));

    Assert.IsInstanceOfType(service.Logger, typeof(DatabaseLogger));

}

現(xiàn)在我們已經(jīng)可以使用Fluent Interface對IService實例的初始化過程進行配置了。Fluent Interface的引入，更像是在使用一種自然語言對配置過程進行表述：Service factory, to config (the) service with Appfabric Cache (mechanism) (and) with Database Logger (mechanism)。

總結(jié)

本文首先介紹了Fluent Interface的相關(guān)知識，并給出了一種簡單的實現(xiàn)方式。通過對簡單實現(xiàn)方式的討論，引出了可能存在的設(shè)計問題，進而選擇了一種更為合理的實現(xiàn)方式，即通過使用裝飾器模式和C#的擴展方法特性來實現(xiàn)Fluent Interface。這種全新的實現(xiàn)方式不僅能夠解決所討論的設(shè)計問題，而且這種面向?qū)ο蟮脑O(shè)計方式還為Fluent Interface的實現(xiàn)帶來了一定的可擴展性。文章最后對這種實現(xiàn)方式進行了簡單測試，同時也展示了Fluent Interface在實際中的應(yīng)用。

您可能感興趣的文章: