Base Classes and Factory Pattern
-
I use an IMessageTransport to send various B2B messages and receive replies. It has various methods related to various business functions, so e.g. I will pass a DocumentMessage to the SubmitDocument method, or a StatusRequest to the GetDocStatus method. A requirement has arisen to include, lets call it, a SenderID, with each message sent. Now, before I do any refactoring, I need a Guid SenderID param for each IMessageTransport method. Now, to remove this duplication I could delegate the insertion of the SenderID to the implementors of IMessageTransport, but I may want to allow these to also send messages from other senders. I seem to have two choices: all IMessageTransport methods must be passed an object that derives from MessageBase, which exposes a SenderID property, and populates this from config, or an IMessage interface, with the same property that is populated by a sender dedicated factory class. Which would be the better direction to look in?
-
I use an IMessageTransport to send various B2B messages and receive replies. It has various methods related to various business functions, so e.g. I will pass a DocumentMessage to the SubmitDocument method, or a StatusRequest to the GetDocStatus method. A requirement has arisen to include, lets call it, a SenderID, with each message sent. Now, before I do any refactoring, I need a Guid SenderID param for each IMessageTransport method. Now, to remove this duplication I could delegate the insertion of the SenderID to the implementors of IMessageTransport, but I may want to allow these to also send messages from other senders. I seem to have two choices: all IMessageTransport methods must be passed an object that derives from MessageBase, which exposes a SenderID property, and populates this from config, or an IMessage interface, with the same property that is populated by a sender dedicated factory class. Which would be the better direction to look in?
I would definitely go with the Factory pattern. It gives you more flexibility later on, especially if things change further down the line.
Deja View - the feeling that you've seen this post before.
-
I use an IMessageTransport to send various B2B messages and receive replies. It has various methods related to various business functions, so e.g. I will pass a DocumentMessage to the SubmitDocument method, or a StatusRequest to the GetDocStatus method. A requirement has arisen to include, lets call it, a SenderID, with each message sent. Now, before I do any refactoring, I need a Guid SenderID param for each IMessageTransport method. Now, to remove this duplication I could delegate the insertion of the SenderID to the implementors of IMessageTransport, but I may want to allow these to also send messages from other senders. I seem to have two choices: all IMessageTransport methods must be passed an object that derives from MessageBase, which exposes a SenderID property, and populates this from config, or an IMessage interface, with the same property that is populated by a sender dedicated factory class. Which would be the better direction to look in?
-
Brady Kelly wrote:
I need a Guid SenderID param for each IMessageTransport method.
You need a GUID for each method? :confused:
led mike
Yes, but the same one. Until a point, I have separated the sender ID from the business information, as at the interface to our other system there is always only one sender, but I prefer not to fix a single sender ID in my transport. Therefore between the transport layer getting a message to send, and sending it, it must determine a sender ID. At the moment it's passed with the message as a parameter.
My Blog