Структура решения Ultimate Visual Studio

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

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

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

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

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

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

Экранные снимки
CoreUI

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

Ответы

Ответ 1

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

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

Ответ 2

Ницца Wiki.

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

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

alt text

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

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

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

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

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

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

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

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

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

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

Что мои два цента (за что это стоит).

Ответ 3

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

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

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

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

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

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