Окончательная структура решения Visual Studio - PullRequest
45 голосов
/ 19 августа 2010

Понимая, что это может быть субъективно в зависимости от проекта, я ищу "наилучший метод" структурирования решения VS (Visual Studio).

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

Ниже приведено то, что я сейчас работаю для меня (над моим текущим проектом), однако я точно знаю, что некоторые вещи находятся не в том месте. В моем сценарии я создаю веб-приложение , используя MVC 2

Пожалуйста, опубликуйте ваше представление о структуре окончательного решения, чтобы мы могли получить представление о "наилучшем способе" / "наилучшей практике" (, что бы это ни значило )

IE:
Как вы разбиваете свой DAL (уровень доступа к данным) / BLL (бизнес-логический уровень)?
Вы помещаете свой слой хранилища и слой обслуживания в свой BLL? Если вы используете MVC (Model-View-Controller), сохраняете ли вы свои контроллеры в пользовательском интерфейсе вместо ядра?
Вы выбрасываете много вещей в папки «Утилиты / Разное» или разбиваете их еще дальше?
и т.д ...


  • MySolution
    • MySolution.Core
      • Аутентификация
        • здесь у меня есть POCO и метод для поиска poco в разделе userData файла auth cookie
      • Base
        • здесь я храню свой BaseController и BaseGlobal
      • Контроллеры
        • все мои контроллеры (очевидно)
      • Домен
        • DatabaseModels
          • содержит мой файл L2S .dbml
        • JsonModels
          • модели, используемые для передачи объектов JSON в veiw
        • Хранилища
        • Услуга
        • ViewModels
      • Расширения
        • все методы расширения
      • Фильтры
        • Фильтры действий
      • Утилиты
        • Апис
          • здесь указан весь сторонний код API
        • Значки
          • здесь идет расчет значка
        • MailClient
          • отправьте текстовое или html электронное письмо, используя классы здесь
        • RoutingHelpers
          • содержит класс для включения строчных маршрутов
        • также содержит вещи, которые я не знаю, куда еще поместить ... IE: HTMLSanitizer, пользовательские HtmlHelpers, помощник UserInfo (IP-адрес, браузер и т. Д.), DataConverter и т. Д.
    • MySolution.UI
      • App_Browsers
      • Активы
        • Css
        • Изображения
        • Скрипты
      • Просмотры
      • Global.asax - наследуется от BaseGlobal
      • Web.config

Снимки экрана
CoreUI

Пожалуйста, не стесняйтесь комментировать соответственно, или еще лучше, опубликуйте свою версию (ответ) ниже. Я знаю, что то, что у меня есть, не лучший способ.

Ответы [ 3 ]

10 голосов
/ 15 сентября 2010

Nice Wiki.

Я начинаю новый проект, и это структура, с которой я начал.

Это соответствует рекомендациям Microsoft (бизнес, данные, услуги, презентация).

alt text

В моем решении:

  • Бизнес: логика, относящаяся к области / проекту, и прежде всего POCO.
  • Данные: репозитории.не требует пояснений.
  • Услуги: логика поверх хранилищ.я могу добавить сюда кэширование, фильтрацию и т. д. Мой пользовательский интерфейс связывается с хранилищем через службы, а не напрямую с хранилищем.(взаимно-однозначная зависимость для пользовательского интерфейса).
  • Презентация: приложение MVC (TBD).

Вы заметите, что у меня также есть привычка ставить префикс к фактическому имени сборки проектас FQN.

Мне просто нравится его внешний вид, плюс в Object Explorer все это выглядит красиво и "древовидно".

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

Конечно,выше это отправная точка.Все, что у меня сейчас есть, это репозиторий, который возвращает пользователей, и сервисы, которые применяют логику поверх него (фильтрация).

Со временем у меня будет больше бизнес-проектов, больше репозиториев (по одному для каждой логической области сети).приложения), больше сервисов (внешние API, интеграция) и, конечно, у меня ничего нет в Presentation (я делаю TDD).

Мне также нравится, когда все зависимости находятся в одном месте (папка проекта).

Для расширений у меня есть один класс (Extensions.cs) для каждого проекта.Другими словами, я "Расширяю" хранилище, или "Расширяю" пользовательскую службу, или "Расширяю" некоторые функциональные возможности пользовательского интерфейса.

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

Это мои два цента (для чего это стоит).

7 голосов
/ 19 августа 2010

Есть возможности для совершенствования.

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

Моя конечная цель - НИКОГДА не писать код в нескольких местах, а использовать его повторно.

Пользовательский интерфейс и доступ к данным очевидны.

Все, что касается проекта, над которым я работаю, входит в проект Business.

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

7 голосов
/ 19 августа 2010

Ваше решение / структура проекта выглядит для меня довольно здраво. Если вы никогда не смотрели на S # arp Architecture , вы можете захотеть. Основное различие между вашей структурой и архитектурой S # arp заключается в том, что S # arp разбивает контроллеры, службы и репозитории на отдельные проекты. Основным преимуществом этого является то, что становится проще устанавливать границы для ваших зависимостей (например, вы не будете случайно получать доступ к определенным библиотекам данных из кода в Core).

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

...