設計模式命名和澄清：供應商，服務，經紀人

有人能爲我定義供應商，服務和經紀人之間的概念區別嗎？設計模式命名和澄清：供應商，服務，經紀人

我經常編寫MVC應用程序，並將大部分業務邏輯卸載到其他類中。沒什麼奇特的，只需傳入參數並接收POCO實例即可。

什麼是正確的標籤，讓那些類爲我的控制器執行繁重的工作？

來源

2011-09-29 Shawn

有趣的問題，但（供應商，服務商，經紀人）是指命名規則。它不是一個設計模式（正如你在標題中承認的那樣）！你是否同意我的觀點？ –

這是我的理解，有供應商和經紀人的設計模式，但我可能是錯的。但是，是的，你是對的，我的具體問題是關於我介紹的行爲的命名約定。什麼來命名我卸下責任的班級。 – Shawn

經紀人在其他對象之間傳輸數據或事件。它比（例如）提供者更積極，但傾向於轉移。有點像現實生活中的經紀人，它實際上並不提供服務。 –

提供方是真正爲Strategy Pattern

通常，當有人提及了他們在談論到可能存在許多實現一些抽象的合同供應商的另一個名稱。

//As an abstract base class 
public void SetupRoles(RoleProvider provider){} 

//As an interface 
public void SetupRoles(IRoleProvider provider){} 

//As a delegate 
public void SetupRoles(Action<String> addRole){}

服務通常意味着指示只有方法的無狀態對象。服務可以用作戰略，但不一定非要。

//Plain old service... doesn't even need the web 
// CRAZY TALK MAN!!! 
public static class RoleService 
{ 
    public static void SetupRoles(){}; 
    public static String[] GetRoles(){}; 
}

一個Broker實際上只是嗯...經紀負責。它旨在在服務和對象之間移動消息，協調服務之間的交互以保持它們之間的隔離。

public class Broker 
{ 
    public void SendImportantMessage(Message msg) 
    { 
     //Do some important processing here 
     // Maybe some validation 
     NotifySomeOtherServiceOrClassOrMaybeBobFromAccounting(msg); 
    } 
}

來源

2011-09-29 16:20:43 Josh

這正是我所期待的。優秀的解釋。謝謝。 – Shawn

這些似乎是架構模式相對於設計模式;

來源

2011-09-29 17:13:05

設計模式命名和澄清：供應商，服務，經紀人

回答

相關問題