面向服務架構~面向服務的API是統一接口還是具體業務使用具體的接口?

前言說明:這裡說的"接口"并不是C#時的interface,而一般指定一個方法簽名,它一般為外部提供一個GET請求,接口到請求後,進行處理,然後對調用方進行資訊的傳回.

回到本題中來,事件上,我們坐下來,認真去想想,還是統一接口的比較好,如果要具體業務使用具體接口,那它的具體接口肯定也是去再調用一下"那個統一的入口子產品"的,注意,這裡我說的是"子產品",而不是"接口,類,方法等"

大體流程應該是這樣:

用戶端調用某個服務接口

接口系統

調用某體業務前的邏輯

    建立一個具體業務

調用某體業務後的邏輯

傳回給用戶端

對于一個服務端的代碼要求應該是這樣:

1 接口對外具有穩定性

2 對自己具體很好的擴充性(開閉原則)

3 每種具體業務都是獨立的(單一職責原則)

對于上述要求,我設計如下代碼:

1     /// <summary>
 2     /// 對外統一接口子產品
 3     /// </summary>
 4     public class SOA : Controller
 5     {
 6         /// <summary>
 7         /// 統一接口方法,外面可以使用GET請求
 8         /// </summary>
 9         /// <param name="blockName"></param>
10         /// <param name="param"></param>
11         /// <returns></returns>
12         public ContentResult UserAPI(string blockName, string param)
13         {
14             IAPI create = (IAPI)System.Reflection.Assembly.Load("dll").CreateInstance("namespace" + blockName);
15             if (create.Create(param))
16                 return Content("成功");
17             else
18                 return Content("失敗");
19         }
20     }
21 
22     /// <summary>
23     /// 建立API指定接口規範
24     /// </summary>
25     internal interface IAPI
26     {
27         bool Create(string param);
28     }
29 
30     /// <summary>
31     /// 添加購買動态的服務
32     /// </summary>
33     internal class AddBuyingNews : IAPI
34     {
35         public bool Create(string param)
36         {
37             return true;
38         }
39     }
40 
41     /// <summary>
42     /// 添加使用者等級的服務
43     /// </summary>
44     internal class AddUserLevel : IAPI
45     {
46         public bool Create(string param)
47         {
48             return true;
49         }
50      

通過上面代碼,我們可以看到,對外統一UserAPI是穩定的,當業務有變化直接修改具體業務即可,用戶端平台不用修改,而AddBuyingNews和AddUserLevel這兩個類型是實作各自業務的,它們之間是獨立的,功能是單一的,這符合單一職責,而如果服務層希望擴充新的業務隻要建立一個新類型即可,對外統一接口UserAPI不用改變,因為具體業務已經通過反射實作了松耦合,有人說反射會對性能有很大的影響,事實上,不是這樣的,細心的朋友可以看一下.net自己的托管的類庫,用了大量的反射,為何要用反射?我會在另一篇文章中去說明,今天主要講的就是這些,呵呵.