Есть ли предлагаемая структура решения для ASP.NET MVC Production Apps? - PullRequest
Новая
       72

Есть ли предлагаемая структура решения для ASP.NET MVC Production Apps?

4 голосов
/ 25 марта 2010

В общем, я не люблю хранить код (BaseClasses или DataAccess Code) в каталоге App_Code сайта ASP.NET. Я обычно вытаскиваю эти вещи в DLL-библиотеки MySite.BusinessLogic и MySite.DataAccess соответственно.

Мне интересно, стоит ли делать то же самое для ASP.NET MVC.

Было бы лучше организовать решение по принципу

  • MySite.Common - DLL - (базовая функциональность, построенная на .NET System Dlls)
  • MySite.DAL - DLL - (файлы DataAccessLayer & DBML)
  • MySite.Models - DLL - (модели MVC, например, классы репозитория)
  • MySite.Controllers - DLL (контроллеры MVC, использующие модели)
  • MySite - сайт ASP.NET MVC.

Или я что-то упустил ... возможно, я потеряю некоторые из приятных (Add View, Go To Controller, пункты контекстного меню, которые были добавлены)

Ответы [ 3 ]

3 голосов
/ 25 марта 2010

В большинстве случаев отлично работает следующая структура:

  • MySite.BusinessLogic (контроллеры, модели, репозитории, ...)
  • MySite.BusinessLogic.Tests (модульные тесты для контроллеров, моделей, репозиториев, ...)
  • MySiteA (просмотры, статическое содержимое)
  • MySiteB (просмотры, статическое содержимое)

MySiteA и MySiteB могут быть двумя разновидностями одного и того же сайта, повторно используя функциональность бизнес-логики.

С точки зрения производительности вы должны предпочитать меньшее количество больших сборок, чем множество небольших сборок.

3 голосов
/ 25 марта 2010

Я только сделал несколько проектов с использованием MVC, но используя вашу структуру имен, мы сделали следующее:

  • MySite.Common - DLL - (базовая функциональность, построенная на .NET System Dlls)
  • MySite.DAL - DLL - (DataAccessLayer & Файлы DBML и модели репозитория)
  • MySite.Models - включены как часть веб-приложения MVC и имел только модели, характерные для видов, которые не всегда сопоставлять один к одному для каждого модель хранилища.
  • MySite.Controllers - включены как часть приложения MVC, но может ссылаться на бизнес-уровень
  • MySite - приложение MVC.

В итоге в моем решении MVC были реализованы следующие проекты:

  • MVC Web App - содержит контроллеры, просмотр моделей для сопоставления данных DAL.
  • Общее - функциональность, которую можно использовать в других приложениях
  • DAL - содержит все данные, связанные с доступом к данным, включая классы-оболочки
  • BL - необязательно в зависимости от того, требуется ли много логики, специфичной для бизнеса
  • Тесты

EDIT: Мои DAL всегда выводят обернутые объекты (при использовании Linq2Sql я автоматически сопоставляю автоматически созданные классы с моими классами в DAL). Единственными классами, которые существуют в приложении MVC, являются контейнеры, которые представляют viwes и в основном используются для передачи данных в представления.

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

2 голосов
/ 25 марта 2010

Мы делаем что-то немного другое

  • [Имя базы данных] .Database.DLL (файлы DBML для конкретной базы данных)
  • [Имя базы данных] .Services. [Домен проблемы] .DLL (который содержит модели, службы и хранилища)
  • [Имя базы данных] .Services. [Проблемный домен] .Tests.DLL
  • [Имя базы данных] .Services.DLL (когда все вышеперечисленное прекрасно вписывается в один сервисный проект)
  • [Имя базы данных] .Services.Tests.DLL
  • [Проблемный домен] .Services.DLL (бизнес-логика по проблемному домену)
  • [Проблемный домен] .Services.Tests.DLL
  • Web.Framework.DLL (повторно используемые компоненты ASP.NET и MVC)
  • Web.Framework.Tests.DLL
  • MySite.Web.DLL (приложение MVC, включая ViewModels)
  • MySite.Web.Tests.DLL

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

В модуле Сервисов у нас будет следующая структура

  • \ Models
  • \ Хранилища
  • \ Services
  • \ и т.д.
...