I am currently working with a system that acts like a message bus. A message comes in to the service (WCF Windows Service hosted). The system then uses a service locator pattern to look up which dynamically loaded assembly will be assigned to the message. The assembly is found and then a method is executed which handles the message. The response is then sent back to the client.
The problem is that the message base is growing enormous, as well as their associated plugins. And there is a lot of code duplication. Let me give a few examples:
- Get_something_related_to_order_Message etc, etc...
As you can see, the messages are very specific. The messages themselves are simple data contracts and they contain zero business logic.
On top of this problem, there is a plug-in for some of these messages that just handles one message. Therefore, there is almost a plugin for every message type!! The system appears to support a one-to-many relationship for a message/plugin, but it appears that all the implementations are one-to-one.
How could I refactor these to reduce code duplication and make the system smarter? I would like the code to be more easily digested to developers because there is a lot of duplication happening.
(Due to some constraints, I cannot use an ORM for data access/entity creation)
In response to Robert Harvey's comment below, I would like to clarify the following:
In 99% of the use cases, the plug-in layer is just simply wrapping a data access call. Here's how it might look.
Request of GetOrderMessage -> Order Plug-in -> Order Data Access (ADO.NET, hand-rolled stored procedure of usp_GetOrder) -> value returned from Order Plug-in -> Response of GetOrderMessage returned to client