0

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.
SaguiItay
  • 2,145
  • 1
  • 18
  • 40
  • 2
    The way you've laid out the pros/cons doesn't make any sense. Create multiple projects in one solution; problem solved. Everything's squeaky clean, easy to update, you don't violate single responsibility, etc. etc. If Visual Studio gets too slow, right-click on the projects you're not working on in the Solution Explorer and select "Unload Project". This is precisely what solutions were *designed* for. – Cody Gray - on strike Jul 25 '11 at 16:08
  • @Cody: I'm well aware that projects are designed for this. However, just "popping-up" more and more projects, without thinking about it, is a bad practice. And you can't get away from the fact that more projects results in slower VS (and unloading projects is not really a solution), and slower build time. AND add to that the fact that you need to manage/deploy/etc each assembly you add... – SaguiItay Jul 25 '11 at 16:29
  • @Saguiltay, After your queue projects are mature and not being changed anymore, you can just distribute the dlls and include those in projects. That way you don't every have to build the queues. – tster Jul 28 '11 at 02:27

1 Answers1

2

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.

Raptor563
  • 56
  • 5