Visual Studio решение / организация проектов

Question

Допустим, вы создаете сложную серверную систему.Где-то в системе у вас есть интерфейс IQueue.Вы планируете иметь несколько реализаций для очереди:

• Наивный "в памяти"
• База данных (где очередь управляется в базе данных)
• AmazonSQS (с использованием сервиса Amazon SQS в облаке)
• MS / Google / Другие службы очередей

Очевидно, что каждая реализация потребует своего собственного класса и реализации.Каждая реализация, вероятно, будет нуждаться в различных ссылках (база данных потребует, чтобы библиотеки DLL связывались с соответствующей базой данных, Amazon SQS потребует библиотеки DLL Amazon AWS и т. Д.)

Как бы вы организовали решение для такого сценария?

Предполагая, что интерфейс и наивная реализация являются местами в проекте, где используется очередь, я вижу следующие возможные варианты:

• Отдельная Visual Studio (и, следовательно, сборка) для каждогореализация:
  • Pro: более чистые проекты, «единая ответственность» на уровне проекта, проще обновить конкретную реализацию
  • Con: много проектов, много сборок для управления / развертывания, медленнее Visual Studio
• Один проект для всех «не наивных» реализаций:
  • Pro / Con: полная противоположность первой опции.

Answer 1

По моему мнению, лучше всего идти по первому пути, который вы перечислили с отдельным проектом Visual Studio для каждой реализации, по причинам, которые вы перечислили.Он также имеет дополнительное преимущество, заключающееся в возможности добавлять реализации по мере необходимости без необходимости заменять двоичные файлы, что довольно приятно.