Поиск предложений по решению для Microsoft Visual Studio и соглашениям об именах проектов - PullRequest
Новая
       13

Поиск предложений по решению для Microsoft Visual Studio и соглашениям об именах проектов

7 голосов
/ 06 октября 2010

Похоже, что нет проверенного и достоверного набора лучших практик, которые бы помогли вам настроить ваши решения, проекты и сборки, которые они выводят. Microsoft, похоже, пытался попробовать в дни VS.net, но с тех пор они удалили этот контент. Для каждого метода, о котором я читаю, я читаю другой, который утверждает, что лучше наоборот, или пост, который касается только «если бы только Microsoft ...», но на самом деле не предлагает решений.

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

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

Какие условности вы используете для ...

  • Назовите ваши решения и почему?
  • Назовите свои проекты и почему?
  • Назовите ваши сборки и почему?
  • знаете, когда создать новый проект или добавить в существующий проект и почему?
  • знает, когда разделить решение на более мелкие решения и почему?
  • знаете, когда разбить проект на несколько проектов и почему?

Просто чтобы прояснить, ПОЧЕМУ так же важно, как и КАК в этих ответах. Есть много ответов о том, как здесь и в других местах, очень немногие говорят, почему они используют одно соглашение над другим.

Ответы [ 3 ]

3 голосов
/ 06 октября 2010

Это очень широкий вопрос, но хороший. Я начну с простой структуры, которую я использую для веб-проектов ASP.Net (MVC будет выглядеть совершенно иначе).

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

Название проекта очень важно для меня. 

// class library that supports the site itself and abstracts
// more complicated UI logic into a separate place
Company.ProductName.Web;

// website
Company.ProductName.Web.UI;

// main business object library for product
//
// of course, you can have as many of these as needed.
Company.ProductName;

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

Мой типичный веб-проект выглядит примерно так. Обратите внимание на различия в регистре для представления пространств имен / компилируемых ресурсов по сравнению с теми, которые не являются.

  • клиент (css, javascript)
  • config (личные, пользовательские файлы конфигурации, если есть)
  • Содержимое (главные страницы, ASPX и ASCX, разбитые на логические папки)
  • Обработчики (ASHX и тому подобное)
  • изображения
  • MSBuild (сборка скриптов)
  • Веб-сервисы (это должны быть ТОЛЬКО небольшие сервисы, которые имеют прямое отношение к рассматриваемому сайту. В противном случае, разбейте их на отдельный проект).

Я начал использовать частичные классы все больше и больше, чтобы создавать всеобъемлющие классы, которые могут делать много вещей, не загромождая код. Например, я недавно создал веб-сервис, единственной целью которого является возвращение JSON клиенту, но логика распределена по почти дюжине частичных классов для лучшей его организации.

Надеюсь, что вы начали.

2 голосов
/ 06 октября 2010

Как говорит Тим, это очень широко.Несколько вещей, на которые стоит обратить внимание:

  • Решением обычно является просто коллекция проектов.Например, многие решения могут включать одни и те же проекты.Таким образом, это не имеет большого значения: если вам не нравится имя решения, вы можете выбросить его без рефакторинга вообще.
  • Как и Pradeep, я склонен называть проекты с верхним уровнемпространство имен они содержат.«Более глубокие» пространства имен оказываются в подкаталогах, поэтому классы в пространстве имен Foo.Bar.Baz могут находиться в каталоге Baz проекта Foo.Bar.

Я склонен разбиваться на проекты по:

  • Элементы многократного использования (например, одна сборка для пользовательского интерфейса, одна для повторно используемого набора классов моделей, одна для многоразовых универсальных служебных классов)
  • Элементы развертывания (например, одна для производства(один для тестирования, в парах)
  • Элементы ссылки (например, если у вас есть общая сборка Skeety.Common с некоторыми интерфейсами, используемыми другими классами, может быть сборка Skeety.Common.Testing, содержащая типы, которые помогут вамтестовые занятия с использованием Skeety.Common).Это приводит к следующим правилам:
    • Производственные сборки могут относиться только к другим рабочим сборкам
    • Испытательные сборки могут относиться только к рабочим сборкам и другим рабочим сборкам
    • Испытательные сборки (содержащие сами тесты) может относиться только к производственным и тестовым сборкам, но не к другим тестовым сборкам
    • Круговые ссылки не допускаются, очевидно,

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

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

2 голосов
/ 06 октября 2010

В нашем случае мы сохраняем имена наших проектов совершенно идентичными пространствам имен, которые мы выбрали для конкретной сборки. Таким образом, становится легко отобразить местоположение файла класса в физической папке. Например - CompanyName.BusinessLine.BusinessService или CompanyName.Framework.Security. Поэтому, если разработчик смотрит на CompanyName.Framework.Security.Cryptography.cs, он может сразу выяснить проект и открыть этот проект.

...