How do I architect 2 plugins that share a common component?

Question

I have an object that takes in data and spits out a transformed output, called IBaseItem.

I also have two parsers, IParserA and IParserB. These parsers transform external data (in format dataA and dataB respectively) to a format usable by my IBaseItem (baseData).

I want to create 2 systems, one that works with dataA and one that works with dataB. They will allow the user to enter data and match it to the right plugins/implementations and transform the data to outData.

I want to write these traffic cops myself, but have other people provide the parsers and baseitem logic, and and as such am implementing these items as plugins (hence the use of interfaces). Other programmers can choose to implement 1 or both parsers.

Q: How should I structure the way base items and parsers are associated, stored, and loaded into each of my programs?

Class Relations:

What I've Tried:

Initially I though there should be a different dll for each of my 2 traffic cops, that each have a parser and baseitem in them. However, the duplication of baseitem logic doesn't seem right (especially if the base item logic changes).

I then thought the base items could all have their own dll, and then somehow associate parsers and baseitems (guids?), but I don't know if implementing the overhead id/association is adding too much complexion.

Answer 1

I'd structure this solution like this:

• You would have a single assembly which contains the IBaseItem contract (and any other contracts you expose to your consumers). Call this a contract assembly.
• You may then need a second assembly which contains any shared code for your two parsers. Depending on the nature of your solution this shared code could go in the contract assembly, or may need to go into a base parser logic assembly. This base parser assembly would almost certainly need to reference the contract assembly to perform basic functions.
• Finally, the two parsers can exist in their own projects and reference both of the other assemblies.

I don't follow with the mention of associating parsers with baseitems through guids. The question only mentions one baseitem, and each parser only knows one data type - it's a simple enough process to parse your one known input type into your one known output type.