Существует ли рекомендуемая структура решения для производственных приложений ASP.NET MVC?

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

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

Было бы лучше Организовать решение что-то вроде

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

Или я что-то упустил... предположительно, я потеряю некоторые приятные вещи (Добавить представление, Перейти к контроллеру, элементы контекстного меню, которые были добавлены)


asp.net-mvc structure solution code-organization projects-and-solutions
person Eoin Campbell    schedule 25.03.2010    source источник

Ответы (3)


arrow_upward
3
arrow_downward

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

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

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

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

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

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

person Kelsey    schedule 25.03.2010
comment
да, это почти то же самое, что я делал в прошлом для Standard ASP.NET (Common, DAL, BLL), но просто кажется беспорядочным иметь код DAL в одной DLL и код репозитория DAL на сайте... аналогично, у нас может быть требование сделать новую мобильную версию нашего сайта в MVC, но как другое приложение, размещенное на другом сервере, поэтому было бы неплохо иметь возможность повторно использовать контроллеры/модели из библиотеки и просто нужно напишите новые взгляды. - person Eoin Campbell; 25.03.2010

arrow_upward
3
arrow_downward

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

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

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

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

person Darin Dimitrov    schedule 25.03.2010

arrow_upward
2
arrow_downward

Мы делаем вещи немного по-другому

  • [Имя базы данных].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

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

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

  • \Модели
  • \Репозитории
  • \Услуги
  • \и т.д.
person Todd Smith    schedule 25.03.2010