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

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

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

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

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

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

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

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

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

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

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

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

Спасибо!