2013-04-10 7 views
0

在我的公司,我們的服務實現基本上只是將回調傳遞給業務層,該業務層進行實際處理。因此,舉例來說,如果我們有一個服務合同,看起來像這樣:動態生成服務實現

public interface IService 
{ 
    void ServiceMethod1(string a, object b); 
    int ServiceMethod2(int a, int b); 
} 

我們的服務可能看起來就像這樣:

public class Service : IService 
{ 
    private ServiceBL _serviceBL; 

    public Service() 
    { 
     _serviceBL = new ServiceBL(); 
    } 

    public void ServiceMethod1(string a, object b) 
    { 
     _serviceBL.ServiceMethod1(a, b); 
    } 

    public int ServiceMethod2(int a, int b) 
    { 
     return _serviceBL.ServiceMethod2(a, b); 
    } 
} 

因爲這個變得相當重複的,我不知道是否有我可以根據合同自行發出服務方法。我希望的代碼可能是這個樣子:

public abstract class MagicServiceBase<T> 
{ 
    protected dynamic InterfaceImplementor { get; } 

    public MagicServiceBase() 
    { 
     // Magic that makes the methods defined in T real. 
    } 
} 

public class Service : MagicServiceBase<IService>, IService 
{ 
    protected override dynamic InterfaceImplementor 
    { 
     get 
     { 
      return new ServiceBL(); 
     } 
    } 
} 

有沒有一種方法來創建此,還是我只是想成爲合理懶得?

+0

我認爲服務和業務層聽起來像同義詞。其中一個是不必要的。 – duffymo 2013-04-10 12:38:03

+0

@duffymo:我一般聽說把你的服務契約實現與實際的業務邏輯分開是一件好事。 – zimdanen 2013-04-10 12:51:28

+0

你沒有分開任何東西;聽起來像通過。我看不到任何事務或其他任何東西來區分您的自動生成的服務層。爲什麼生成無意義的代碼?我有基於接口的服務,但我給他們一些有意義的事情。我讓他們成爲工作單位的所有者和編排者。 – duffymo 2013-04-10 12:52:33

回答

0

你應該看看阿加莎(http://davybrion.github.io/Agatha/) 這是一個框架,爲您的服務刪除這樣的設置的要求。

你必須註冊消息請求和響應,它是根據處理程序。
您可以使用此框架來封裝所需的所有服務行爲,並獲得您的處理邏輯的清晰分離。

一個偉大的框架,實現乾淨的wcf服務。不是調用yourService.Methods,而是實際上調度您的請求並接收您的響應。

+0

現在就讀一讀吧。 – zimdanen 2013-04-10 12:51:52

相關問題