Design Pattern Nomenclature and clarification: supplier, service, broker

Can someone determine for me the conceptual difference between the Provider, the Service and the Broker?

I regularly write MVC applications and upload most of the business logic to other classes. Nothing out of the ordinary, just pass the parameters and get the POCO instances back.

What is the correct label to give these classes a heavy lift for my controller?

+7
source share
2 answers

The provider is actually just another name for the Strategy Template

Usually, when someone mentions the use of a provider, he talks about some kind of abstract contract to which many implementations can exist.

//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){} 

A service is usually intended to indicate an object without a state that has only methods on it. The service can be used as a Strategy, but it does not have to be.

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

A Broker is really just responsible for ... brokerage. It is designed to move messages between services and objects, organize interaction between services in order to isolate them.

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

These are, apparently, architectural patterns, not design patterns;

+2
source

All Articles