Когда вы решили разделить большие проекты на более мелкие?

Question

Когда / где вы решили разделить большой проект Visual Studio на несколько небольших проектов? Если это может быть многоразовым? когда проект слишком большой? (но насколько большой слишком большой?)

и когда вы делите проект, вы

• группировка по таблицам базы данных

• группировка по аналогичной функциональности

• другой ..

Answer 1

Плюсы многих проектов:

• Проще выделить код для модульного тестирования. Мне нравится выделять код, который зависит от большого внешнего сервера, например, код, который обращается к SMTP-серверу, получает свою собственную сборку, код, который обращается к базе данных, получает свою собственную сборку, код, который обращается к веб-серверу, код, который это чистая бизнес-логика, как проверки.

Плюсы нескольких проектов:

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

Плюсы многих решений

• Вы достигли максимального уровня проекта позже.
• Каждый раз, когда вы нажимаете f5 *, компилируется только то, что есть в вашем текущем решении.
• Если от проекта не ожидается изменений в жизни вашего приложения, зачем перекомпилировать его снова и снова? Вызовите это сделано и переместите его к собственному решению.

Минусы многих решений

• Вам решать, как определить зависимости между решениями, и сначала вручную скомпилировать зависимости. Это приводит к сложным сценариям сборки.

Answer 2

Проекты должны быть связными . Логика должна быть связана, и достижение аналогичной цели

Этот ответ будет зависеть от размера поддерживаемого вами продукта. В целом мы организуем наши проекты в соответствии с предметной областью и логикой. И мы будем делить их еще дальше: чем больше вы разделяете, тем более организованным вы должны быть, или вы столкнетесь с проблемой рекурсивной зависимости.

Когда я решаю разбить проект, это происходит, когда он становится слишком большим или две области становятся слишком похожими.

Когда сложность возрастает, я не делю таблицы, я обычно делю функциональность.

Повторное использование - еще одно прекрасное время для сокращения строк кода, а также для представления нового проекта. Однако будьте осторожны, сколько «служебных» библиотек вы вводите, потому что они влияют на читабельность / понятность.

Я не думаю, что в песке есть строчка, в которой говорится, что если вы нажали 3k SLOC, у вас слишком много. Все это контекстуально.

Answer 3

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

Я обычно сталкиваюсь с несколькими относительно небольшими проектами Framework, которые определяют интерфейсы для слабой связи между другими проектами, с более крупными проектами для различных типов конкретной функциональности. Это всегда по крайней мере один проект для пользовательского интерфейса и один проект для логики и данных (часто делятся на два проекта, если уровень данных сам по себе становится очень большим.)

Answer 4

У меня всегда есть несколько проектов (и, следовательно, решение), вместо одного проекта со всем моим источником.

В некоторых случаях это неизбежно, потому что вы используете библиотеку с открытым исходным кодом и хотите иметь возможность ее отладки. Но более прагматично, я обычно заставляю свои приложения обеспечивать функциональность через плагины. Это позволяет мне изменить поведение или предложить поведение, выбираемое пользователем во время выполнения. В случае без плагинов, это позволяет вам обновить одну часть вашей программы, не обновляя все. Существуют также случаи, когда вы, очевидно, можете предоставить основное и загружать модули / сборки только тогда, когда они вам нужны.

Еще одна причина заключается в том, что вы можете создавать меньшие тестовые приложения для выполнения сборки, а не создавать очень большое решение и потенциально требовать от пользователя выполнения нескольких (и не относящихся к делу) операций графического интерфейса пользователя даже до достижения части, которую вы хотите протестировать. И это не просто проблема тестирования - возможно, в вашей организации есть менее опытные пользователи, которые хотят, чтобы их представляли только те биты, которые их касаются.

Answer 5

Я перемещаю код в новый проект, если он имеет общие функциональные возможности (теоретически), используемые другими проектами. Если проект большой, поскольку он представляет собой сложную проблему, то пространства имен предоставляют отличный способ навести порядок в коде. Здесь вы можете, например, ввести (под) пространства имен для каждой таблицы SQL и т. Д. И т. Д.