The Ultimate Visual Studio Solution Structure

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

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

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

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

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


  • MySolution
    • MySolution.Core
      • Authentication
        • здесь у меня POCO и метод для поиска poco в секцию userData auth cookie
      • Base
        • здесь у меня BaseController и BaseGlobal
      • Controllers
        • все мои контроллеры (очевидно)
      • Domain
        • DatabaseModels
          • содержит мой L2S . dbml файл
        • JsonModels
          • модели, используемые для передачи JSON объектов в veiw
        • Repositories
        • Services
        • ViewModels
      • Extensions
        • все методы расширения
      • Filters
        • Action Filters
      • Utilities
        • Apis
          • весь код API сторонних разработчиков идет сюда
        • Бейджи
          • расчет бейджей сюда
        • MailClient
          • отправка обычной текстовой или html почты с помощью классов здесь
        • RoutingHelpers
          • содержит класс для включения маршрутов в нижнем регистре
        • также содержит вещи, которые я не знаю куда еще поместить. .. IE: HTMLSanitizer, пользовательские HtmlHelpers, UserInfo helper (IP адрес, браузер и т.д.), DataConverter, etc
    • MySolution.UI
      • App_Browsers
      • Assets
        • Css
        • Images
        • Scripts
      • Views
      • Global. asax - наследуется от BaseGlobal
      • Web.config

Screen Shots
CoreUI

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

46
задан 8 revs, 3 users 73% 11 June 2015 в 15:57
поделиться

2 ответа

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

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

7
ответ дан 26 November 2019 в 20:43
поделиться

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

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

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

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

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

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

7
ответ дан 26 November 2019 в 20:43
поделиться