Существует ли рекомендуемая, рекомендуемая или общепринятая структура для проектов .NET и / или ASP.NET?

Question

Я думаю о том, чтобы начать работу в довольно крупномасштабном проекте .NET или ASP.NET (я еще не решил, но, вероятно, в конечном итоге он будет доступен как из приложения для настольного компьютера, написанного на. NET, а также веб-приложение ASP.NET). Однако я не уверен, есть ли обычный способ структурирования проекта.

Сам проект является инструментом управления ресурсами / знаниями, который отслеживает ряд источников знаний - людей, публикации (книги, журналы, журналы), веб-ресурсы, цифровые документы (включая PDF, документы Word, документы ODF, MP3 и т. Д.). ) и другие, как я считаю нужным. Конечно, поскольку он настолько большой, я хочу иметь возможность внедрять и тестировать один раздел за раз, но объединить их в единую систему.

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

РЕДАКТИРОВАТЬ 1: Я ищу не только шаблоны (например, как указал Торан Биллапс), но также структуры каталогов, структуры проектов (как в проекте VisualStudio) и структуры документации.

Answer 1

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

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

Я бы предложил эту отличную статью из MSDN от великого JP Boodhoo. Я придерживаюсь той же структуры, и большим преимуществом является то, что мой пользовательский интерфейс не управляет моей линией бизнес-приложений. Они также намного более удобны в обслуживании и могут использоваться повторно. У меня может быть приложение веб-форм, использующее ту же библиотеку классов, что и мое приложение WPF.

Answer 2

Для макета дерева кода я обычно делаю что-то вроде этого:

projectname/
           /source/
           /source/projectname.sln
           /source/DataAccess/
           /source/DataAccess/DataAccess.csproj
           /database/schema/
           /database/schema/something.sql
           /database/testdata/
           /database/refdata/
           /tools/
           /COTS/
           /COTS/vendorname/
           /COTS/vendorname/somelib.dll
           /doc/
           /build/
           /installer/
           /projectname.build

Таким образом, каталог верхнего уровня содержит файл сборки проекта. Это может быть ant, make и т. Д. Мы используем FinalBuilder. Затем у вас есть подкаталоги для каждого из источника, базы данных, инструментов, COTS, документа и т. Д. Вы можете думать о других, но это очевидные.

Я обычно включаю папку сборки для подготовки вывода сборки. Именно здесь ваш установщик ищет свои файлы.

В верхней части дерева исходных текстов находится мой файл решения Visual Studio. Каждый подпроект получает свой собственный подкаталог, который содержит свой файл проекта и все остальное. Мне нравится инкапсулировать вещи в довольно небольших проектах, поэтому у меня может быть 10 проектов в решении, каждый со своим собственным подкаталогом в источнике.

Скрипты базы данных могут быть разделены, как вам угодно, но постарайтесь разделить структуру и данные.

Инструменты для разных вещей, которые вам нужны для создания этого проекта.

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