Есть ли рекомендуемая, предлагаемая или обычная структура для проектов .NET и / или ASP.NET?
Я подумываю начать работу над довольно крупномасштабным проектом .NET или ASP.NET (я еще не решил, но вполне вероятно, что в конечном итоге он будет доступен как из настольного приложения, написанного на .NET, так и из него). как веб-приложение ASP.NET). Однако я не уверен, есть ли традиционный способ структурировать проект.
Сам проект представляет собой инструмент управления ресурсами / знаниями, который отслеживает ряд источников знаний - людей, публикации (книги, журналы, журналы), веб-ресурсы, цифровые документы (включая PDF, документы Word, документы ODF, MP3 и другие) и другие. как я считаю нужным. Конечно, из-за того, что он такой большой, я хочу иметь возможность реализовывать и тестировать по одному разделу за раз, но интегрировать их в единую систему.
Как только я закончу и протестирую один или два раздела, я хочу выпустить его как инструмент с открытым исходным кодом. Однако, если другие собираются работать над этим, я хочу представить им простую для понимания структуру. Однако я никогда не работал над проектом ASP.NET и не касался .NET с тех пор, как фреймворк 2.0 был новым. Я ищу любые соглашения, существующие в сообществе .NET, а также любые общие соглашения о том, как можно структурировать такой крупномасштабный проект, чтобы сделать проектирование, разработку, тестирование, использование и обслуживание максимально простым и безболезненным для любой, кто использует или работает над этим проектом.
РЕДАКТИРОВАТЬ 1: Я ищу не только шаблоны (вроде того, что указал Торан Биллапс), но также структуры каталогов, структуры проекта (как в проекте VisualStudio) и структуры документации.
Ответы 2
Если вы работаете с технологией веб-форм и хотите иметь возможность создавать настольное приложение с той же базой кода, я бы предложил использовать шаблон Model View Presenter, чтобы отделить пользовательский интерфейс от бизнес-кодирования. В дополнение к этому подходу я бы рекомендовал создать уровень обслуживания, который обрабатывает логику за пределами класса Presenter (включая доступ к данным / бизнес-логику).
Я обнаружил, что создание библиотеки классов для хранения этого независимого от пользовательского интерфейса кода позволяет очень легко повторно использовать этот код. Эта архитектура также обеспечивает простой переход веб-службы, если вы выберете этот маршрут, потому что входы / выходы вашей службы должны быть такими же в вашей библиотеке классов, как и в веб-службе (WCF или ASMX).
Я бы посоветовал это отличную статью из MSDN великого JP Boodhoo. Я следую этой же структуре, и большое преимущество состоит в том, что мой пользовательский интерфейс не влияет на мои бизнес-приложения. Они также более удобны в обслуживании и могут использоваться повторно. У меня может быть приложение веб-форм, использующее ту же библиотеку классов, что и мое приложение WPF.
Для компоновки дерева кода я обычно делаю что-то вроде этого:
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. Каждый подпроект получает свой собственный подкаталог, в котором хранится его файл vs project и все остальное. Мне нравится, когда что-то инкапсулируется в довольно небольшие проекты, поэтому у меня может быть 10 проектов в решении, каждый со своим собственным подкаталогом в исходном коде.
Скрипты базы данных можно разделять, как вам нравится, но старайтесь разделять структуру и данные.
Инструменты предназначены для разных вещей, которые вам понадобятся для создания этого проекта.
COTS предназначен для внешних вещей, которые вы купили или скачали и от которых зависите, но не можете создать самостоятельно.