Как вы структурируете свои источники ASP.net в Visual Studio?

Question

Есть ли у вас одно решение с проектом веб-приложения, библиотеками классов, проектом базы данных и тестами? Или вы разделяете его на несколько решений? Почему?

Я спрашиваю, потому что мы пытаемся упростить этот сценарий для Visual Studio 2010, и я хотел бы узнать мнение сообщества о том, как вы предпочитаете работать.

Answer 1

Я склонен (но не всегда) иметь одно решение для каждой работы, но я импортирую существующие проекты из других решений, таких как мой WebControlLibrary, где я храню общие пользовательские элементы управления и классы и т. Д.

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

Solution
...MyCompany.WebControlLibrary
...Project
...Project.BusinessLogic
...Project.DataAccess
...Project.Entities
...Project.Scripts
...Project.Testing
...Project.Deployment

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

MobileSolution
...MobileProject
...Project.Entities
...MobileProject.BusinessLogic

Чем больше «вещей» вы скомбинировали, тем медленнее Visual Studios становится при сборке. Очевидно, что вы можете остановить сборку определенных проектов по умолчанию, но именно тогда вы должны начать создавать свои собственные конфигурации сборки. Если вы собираетесь создавать большие приложения, я бы предложил разбить их на несколько решений. Мне гораздо проще переключаться между решениями, чтобы постоянно менять конфигурацию сборки.

Другой вариант - когда вы создаете свои проекты, вы можете ссылаться на их DLL. Я предпочитаю импортировать указанные проекты в мое решение, так как вам не нужно беспокоиться о ссылках на создаваемую конфигурацию сборки, то есть при выборе DLL из папки Debug или Release.

Answer 2

Это немного зависит от работы, которую выполняет проект.

Для простоты использования просто иметь решение, которое просто содержит все необходимые проекты. Если это большое решение, это может помешать вам позже, когда среда IDE начнет работать медленнее, а время сборки ускорится.

Допустим, один из проектов - это библиотека, используемая вашей компанией для приема карточных платежей и взаимодействия с 3d secure. Вы представляете свою собственную страницу графического интерфейса, чтобы узнать подробности и т.д.

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

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

Answer 3

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