#visual-studio
#visual-studio
Вопрос:
Кажется, мне трудно понять причину необходимости иметь много проектов внутри одного решения (в моем случае visual Studio 2010 с c #).
Единственное, что приходит на ум, — это если я создаю новые классы, я могу сначала протестировать их в консольном приложении, а затем добавить в решение другой проект, чтобы использовать эти классы в проекте, который я хочу.
пожалуйста, направьте меня на правильный путь, спасибо.
Ответ №1:
Типичный проект может иметь пользовательский интерфейс, уровень данных, уровень сервисов и уровень домена, а также некоторые тесты. Типичным решением было бы, чтобы каждый из них существовал как свой собственный файл проекта. Решение будет содержать все эти проекты, чтобы вы могли вносить изменения и отлаживать разные части приложения одновременно.
Если вы только начинаете, вы, вероятно, втиснете все это в один проект. Это прекрасно для обучения, но является абсолютным беспорядком для удобства обслуживания и повторного использования.
Комментарии:
1. Кроме того, как правило, соотношение между решениями и проектами не является соотношением «один ко многим». Каждый проект может быть повторно использован в другом решении (он же другой проект). Это довольно распространенное явление, например, если этот проект является библиотекой.
Ответ №2:
Есть 3 основные причины, которые сразу приходят на ум для разделения вашего решения на несколько проектов: повторное использование, инкапсуляция и настройки, зависящие от конкретного проекта.
-
Повторное использование
Возможно, у вас есть проект утилит, который используется совместно несколькими решениями. У вас также могут быть доступ к данным и бизнес-правила, которые определены в библиотеках классов, но являются общими для нескольких проектов пользовательского интерфейса, например, бизнес-приложение, имеющее веб-интерфейс, интерфейс рабочего стола и веб-службы. Все они должны использовать одну и ту же логику и модель данных, поэтому вам не захочется копировать это в каждом решении отдельно. -
Инкапсуляция
Другая причина заключается в достижении инкапсуляции, одного из основных принципов ООП. Ваши классы могут иметь внутренние методы и свойства (или сами классы могут даже быть определены как внутренние), что делает их видимыми только для других классов в том же проекте. Если оно предназначено для достижения определенной цели, но не для того, что должно быть доступно всем, разделив ваши классы на отдельные проекты, вы можете сделать эти свойства, методы и классы видимыми для ваших классов, но скрытыми за пределами вашего проекта. -
Настройки, зависящие от проекта
Существуют определенные типы проектов, которые ведут себя совершенно иначе друг от друга. Веб-проект отличается от приложения Windows Forms, которое полностью отличается от приложения WPF. Это своего рода соответствует # 1 и попытке добиться повторного использования кода; поскольку у вас не может быть единого проекта, который является веб-сайтом, и приложением Windows Forms И приложением WPF, вы создаете каждый пользовательский интерфейс как отдельный проект и вкладываете как можно больше логики в отдельный проект, который может быть общим для всех проектов пользовательского интерфейса.
Ответ №3:
Пара возможных причин, которые приходят мне в голову:
- проект может быть полезен в нескольких решениях
- простая утилита организации — точно так же, как у вас могут быть классы в отдельных файлах, хотя один исходный файл может содержать несколько классов просто отлично.