根據功能需求，實現單獨的通道來訪問你的商業邏輯。
by Jonathan Goodyear, MCSD, MCP, CLS
大多數商業應用程序只通過Web services給外界提供其功能的一小部分。大多數應用程序的商業邏輯都是在企業內部互聯網中的防火墻后的。而且，在外部和內部，你總是需要同樣的功能。理想情況下，你不需要在兩個不同的地方編寫這個重復的功能——它應該保留在一個集中的商業邏輯層中。要實現這一點，一種方法就是實現多個Web service接口，將它們作為進入你的商業邏輯的通道。我把它們稱作Web service “storefronts”。

例如，假設你在為一個網站構建一個內容管理應用程序。在內部，你可能需要一些功能來增加、更新、刪除和讀取網站內容。如果你允許其它的網站運用你的內容，那么在外部你只需要提供讀取功能。為了適當地封裝你的商業邏輯，你需要將所有這些相關的內容部件功能添加到一個叫做ContentWidget的單獨的集合中（見列表1）。

接下來，你創建兩個單獨的Web service接口，叫做InternalContent和ExternalContent。這兩個Web services都會引用ContentWidget集合。InternalContent Web service為ContentWidget.Server對象提供了每個方法，因為你（大概）需要所有這些方法來管理你的網站的內容（見列表2）。

然而，ExternalContent Web service將只提供GetContentWidget方法來讀取內容，因為對你的網站的內容的外部訪問目的是單一的（見列表3）。注意，InternalContent和ExternalContent Web services都實現了GetContentWidget方法。如果你知道你的內容管理應用程序有權限訪問這兩個Web services，你就可以從InternalContent Web service刪除GetContentWidget方法，作為替代，你可以調用ExternalContent Web service來讀取內容，從而就可以刪除所有的多余的代碼。然而你的內部應用程序并不是總是有權限訪問這兩個Web services的。

Web services storefront方法的好處就是你可以集中所有的商業邏輯，同時也可以控制你給外界提供的功能。需要記住的一個主要的概念是Web services不能用來提供商業邏輯。它們就類似一個ASP.NET Web應用程序中的Web窗體。它們只是方便了不同系統間（或人們之間，在Web forms的情況下——見資源）的交互。確信將IIS驗證添加到InternalContent Web service，以便限制已提供有效安全屬性的應用程序對它的訪問（見資源）。

你也可以用.NET remoting實現同樣的Web service storefront方法。到你的商業邏輯的內部接口和外部接口是分離的，所以你可以同時實現它們。在這個例子中，我選擇在內部和外部都運用了Web services，因為在這種情況下，你的商業邏輯集合就有很好的機會可以與非.NET系統交互。遇到一個.NET remoting應用程序并與之交互的可能性是很細微的（就目前情況來說）。

下載Web services storefront的一個完整的樣例。它包含ContentWidget商業邏輯集合、兩個Web service storefront項目、一個ASP.NET Web應用程序、安裝SQL Server表的腳本和存儲、管理內容數據的存儲過程。


關于作者:
Jonathan Goodyear是ASPSoft(www.aspsoft.com)的總裁，這是個位于Orlando,Fla.的一家Internet咨詢公司。他是位MCSD，是Debugging ASP.NET（New Riders)一書的作者，你可以在www.debuggingasp.net找到它。你可以通過jon@aspsoft.com與他聯系，或者通過他在www.angryCoder.com上的angryCoder eZine同他聯系。