Let’s say that you re creating a complex back-end system. Somewhere in the system, you have an IQueue interface. You are planning to have several implementations for the queue:
- Naive “in-memory”
- Database (where the queue is managed in a database)
- Amazon SQS (using Amazon SQS service in the cloud)
- MS/Google/Other Queuing service
Obviously, each implementation will require it’s own class and implementation. Each implementation will probably need different references (Database will require the DLLs to communicate with the relevant database, Amazon SQS will require the Amazon AWS DLLs, etc.)
How would you organize the solution for such a scenario?
Assuming the interface and the naive implementation are places in the project where the queue is used, I see the following possible options:
- Separate Visual Studio (and therefore assembly) for each implementation:
- Pro: Cleaner projects, “single responsibility” at the project level, easier to update specific implementation
- Con: Many projects, many assemblies to manage/deploy, slower Visual Studio
- Single project for all “non-naive” implementations:
- Pro/Con: exact opposite of first option.
In my opinion, going the first route you listed with a separate Visual Studio project for each implementation is the better one, for the reasons you have listed. It also has the added benefit of being able to add implementations as you go along without have to replace binaries, which is kinda nice.