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

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

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

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

  • Группа по схожей функциональности

  • Другое..

5 19
c# projects-and-solutions

5 ответов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0

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

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

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

0