Сколько проектов в одном решении приемлемо? А для тех приложений, которые имеют большие номера проектов, вы помещаете другие скомпилированные DLL в какую-то общую папку, чтобы иметь возможность запускать приложение?Сколько проектов в решении слишком много?
Поскольку в Visual Studio проект компилируется в сборку, вопрос, который вы должны задать себе, - «сколько сборок у меня есть?»
Если нет каких-либо оснований для использования сборок отдельно, не должно быть причин, по которым они будут разделены на несколько проектов. Если у вас есть несколько сборок для принудительного выравнивания, для этого нужны пространства имен.
В идеальной конфигурации у вас должен быть один проект (= одна сборка) для каждого другого хоста в вашем приложении и один для вашей конкретной логики, отличной от хоста.
YMMV Однако вы можете разделить проекты в соответствии с тем, кто работает с различными частями, но на самом деле попытайтесь ограничить количество проектов в своем решении (поскольку я пишу это, я борюсь с 70+ проектов, поэтому я говорю из бездны моего личного опыта).
интересная дискуссия на логическом/физическом отводками приложений можно найти на блоге Patrick Smacchia (для экземпляра http://codebetter.com/blogs/patricksmacchia/archive/2008/02/10/layering-the-level-metric-and-the-discourse-of-method.aspx)
Слишком много (небольших) сборок затрудняет использование 'internal' (по крайней мере, не прибегая к' [InternalsVisibleTo] '). –
Проблема одного проекта в том, что у вас возникнут проблемы, если вам нужно повторно использовать код из нового приложения. Вы действительно хотите загрузить всю свою бизнес-логику и другие слои в приложение, которое не нуждается в нем? Проблема разлома их состоит в том, что как только вы разломаете один из них, вы будете разрывать многие (например, 42). Я думаю, что больше проектов лучше, если вы планируете расти в конце концов или построить платформу. Если ваше приложение никогда не будет повторно использовано, используйте один проект. Кроме того, я думаю, что лучше организовать и создать новый инструмент на вашем поясе, разделив их. – jwize
Еще одна вещь, заключается в том, что вам ничего не мешает использовать несколько решений (.sln-файлы) для подгрупп тех же проектов. Не только это, но полностью перекрывать проекты для этих решений, поскольку они являются логическими отображениями в одни и те же файлы. Тогда вы можете работать над этими логическими группировками по мере необходимости. – jwize
На это нет правильного или неправильного ответа. Некоторым разработчикам нравится создавать несколько проектов в рамках основного проекта. Другие любят компилировать сборку (dll) и ссылаться обратно. Это зависит от вашей команды и рабочего места.
До тех пор, пока каждый проект является действительной, отдельной функциональностью, и все проекты тесно связаны (насколько это возможно), это не проблема.
Что я делаю, есть ли у меня проект «Библиотеки», где я помещаю все внешние библиотеки DLL, а затем ссылаюсь на них напрямую.
Ну, 42, конечно!
Я думаю, что это то, что зависит от размера и типа ваших проектов. но из моего собственного опыта, когда число моих проектов превышает 5, процесс сборки займет много времени. , поэтому я стараюсь сохранить проекты, которые мне не нужно часто менять в другом решении, чтобы ускорить процесс сборки.
Я согласен с ответами до сих пор. Еще одним критерием является скорость восстановления решения ...
Много «нечетких» факторы влияют на масштабируемость проектов в растворе. Насколько мощна ваша машина? Как вы терпеливы? Сколько решений вам нужно открыть одновременно? Тебе нравится мороженное? Как долго проходит цепочка струн? , , , –
Если вы все время спрашиваете себя, есть ли слишком много проектов, возможно, слишком много проектов! –
Сообщество Wiki кто-нибудь? –