советы по архитектуре приложений asp.net mvc - PullRequest
Новая
       22

советы по архитектуре приложений asp.net mvc

5 голосов
/ 01 сентября 2010

Я использую ASP.net MVC уже около двух лет, и я все еще изучаю лучший способ структурировать приложение.

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

Вот мой основной макет:

  • Проект DataAccess - Содержит все классы репозитория, контексты данных LINQ-to-SQL, фильтры и настраиваемые бизнес-объекты для репозиториев БД, отличных от MS SQL (которых LINQ-to-SQL не делает) т создать). Репозитории обычно имеют только базовую CRUD для объекта, которым они управляют.

  • Сервисный проект - Содержит классы обслуживания, которые выполняют бизнес-логику. Они принимают заказы от контроллеров и сообщают репозиториям, что делать.

  • Проект пользовательского интерфейса - Содержит модели представления и некоторые оболочки для таких вещей, как ConfigurationManager (для модульного тестирования).

  • Основной проект MVC - Содержит контроллеры и представления, а также javascript и css.

Кажется ли это хорошим способом структурировать приложения ASP.NET MVC 2? Любые другие идеи или предложения?

Используются ли модели представлений для всего вывода в представления и ввода из представлений?

Я склоняюсь к пути создания моделей представления для каждого бизнес-объекта, которому необходимо отображать данные в представлении, и превращения их в базовые классы с набором свойств, которые являются строками. Это делает работу с представлениями довольно легкой. Служебный уровень должен затем управлять свойствами сопоставления из модели представления в бизнес-объект. Это является источником некоторых моих недоразумений, потому что большинство примеров, которые я видел на MVC / MVC2, не используют модель представления, если вам не нужно что-то вроде поля со списком.

Если вы используете валидацию новой модели MVC 2, вы бы тогда проверили объект viewmodel, и вам не пришлось бы беспокоиться о размещении атрибутов валидации в бизнес-объектах?

Как выполнить юнит-тестирование этого типа валидации или мне не следует юнит-тестирование, чтобы возвращались сообщения валидации?

Спасибо!

1 Ответ

2 голосов
/ 01 сентября 2010

Интересно.

Одна вещь, которую я делаю по-другому, - это то, что я отделил свой проект DataAccess от своего проекта Domain. Проект домена все еще содержит все интерфейсы для моих репозиториев, но мой проект DataAccess содержит все их конкретные реализации.

Вам не нужны такие вещи, как DataContext, просачивающиеся в ваш доменный проект. Следуя луковой архитектуре , ваш домен не должен иметь никаких зависимостей от внешней инфраструктуры ... Я бы посчитал, что DataAccess должен иметь это, потому что он напрямую связан с базой данных.

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

Приветствия
Charles

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

...