Соглашения о присвоении имен папки C# Project

Хорошая практика - называть папку после имени проекта.

Рекомендации по разработке библиотек классов содержат набор рекомендаций по именам

Последний пункт должен представлять для вас особый интерес:

• Имена сборок и DLL
• Имена пространств имен
• Типы и пространства имен

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

Если неясно, как сгруппировать классы по использованию или значению объектной модели, просто оставьте их все в одной папке. Использование подпапок не дает значений, если они этого не делают. • Организовать классы осмысленным образом.

Разделение папок по типу, например, перечисления, POCO, репозитории, частичные классы и т. д. вряд ли будет полезно.

Вы можете использовать подпапку для сгенерированного кода, который не должен

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

Нет необходимости , чтобы поместить каждое перечисление в свой собственный файл, если перечисление используется только одним классом , допустимо поместить его в тот же файл, что и класс. Например, перечисление PersonSex можно поместить в файл person.cs.

Я (в настоящее время - изменения в зависимости от проекта) обычно использую этот подход при именовании сборок / проектов / пространств имен в проекте в стиле SAAS / Web)

• CompanyName.
  • ProductName.
    • Данные.
    • Бизнес. (справочные данные)
    • Модель. (POCO и интерфейсы - упоминаются всеми)
    • Услуги. (Уровень службы WCF)
    • ServiceClient. (на которые ссылаются веб-клиенты)
    • Web. (бизнес-уровень веб-клиента)
      • ViewModel. (просмотреть конкретную модель)
      • {сегмент продукта, ориентированный на клиента} [Торговля, CMS, CRM, отчетность и т. д.]

Чтобы объяснить услуги / клиент службы ... я использую IoC (в настоящее время StructureMap), который позволяет мне WebClient, чтобы либо разговаривать напрямую с бизнес-уровнем, либо быть перенаправленным для разговора через ServiceClient через службы на бизнес-уровень. Это дает мне гибкость для развертывания уровня моего приложения в моих веб-приложениях или для распределения частей моего бизнес-уровня (уровня приложения) на разные серверы с помощью принципов WCF / SOA.