0
Предположим, что вы создаете сложную внутреннюю систему. Где-то в системе у вас есть интерфейс IQueue. Вы планируете иметь несколько реализаций для очереди:Организация решений/проектов Visual Studio
- Наивные «в памяти»
- Database (где очередь управляется в базе данных)
- Amazon SQS (с помощью сервиса Amazon SQS в облаке)
- MS/Google/Другое Queuing услуги
Очевидно, что каждая реализация потребует его собственный класс и реализация. Каждой реализации, вероятно, понадобятся разные ссылки (для базы данных потребуется, чтобы библиотеки DLL связывались с соответствующей базой данных, Amazon SQS потребует библиотеки Amazon AWS и т. Д.)
Как бы вы могли организовать решение для такого сценария?
Предполагая, что интерфейс и наивную реализацию места в проекте, где используется очередь, я вижу следующие возможные варианты:
- Отдельные Visual Studio (и, следовательно, монтаж) для каждой реализации:
- Pro: чистые проекты, «единая ответственность» на уровне проекта, проще обновлять конкретную реализацию
- Con: Многие проекты, многие сборки для управления/развертывания, более медленные Visual Studio
- Одиночный проект для всех «не наивных» реализаций:
- Pro/Con: полная противоположность первого варианта.
Определенно больше сборок. – TcKs
То, как вы выложили плюсы и минусы, не имеет никакого смысла. Создание нескольких проектов в одном решении; задача решена. Все скрипучие, чистые, легко обновляемые, вы не нарушаете единую ответственность и т. Д. И т. Д. Если Visual Studio становится слишком медленным, щелкните правой кнопкой мыши на проектах, которые вы не работаете в обозревателе решений, и выберите «Выгрузить проект». Именно это решение было разработано * для. –
@ Коди: Я хорошо знаю, что проекты предназначены для этого. Однако просто «всплывающее» все больше и больше проектов, не задумываясь об этом, является плохой практикой. И вы не можете уйти от того факта, что больше проектов приводит к более медленному VS (а проекты разгрузки на самом деле не являются решением) и более медленному времени сборки. И добавьте к этому тот факт, что вам нужно управлять/развертывать/etc каждую сборку, которую вы добавляете ... – SaguiItay