Имеет ли смысл иметь ViewModels в Webapi?

Ответ 1

Терминология в сторону, наличие моделей для привязки до сих пор используется. Они просто не являются технически ViewModels больше, поскольку вы правы, нет никаких взглядов. Но они определенно все еще используются. Используя их, вы можете использовать атрибуты в своих свойствах модели и при необходимости использовать их в своем API. Также помните, если вы используете свои объекты напрямую WebAPI будет моделировать привязать все параметры к ним, которые соответствуют по имени, даже если вы этого не хотели.

Кроме того, модели Entity представляют собой представления ваших необработанных данных, но Модели, используемые для привязки к ним, являются фиксированным контрактом, который запросы API должны удовлетворять, чтобы успешно обрабатывать запрос. Значения, которые могут закончиться развертыванием нескольких моделей сущностей к моменту выполнения вашей реализации, не будут сохраняться в хранилище данных вообще.

Ответ 2

Мое предложение после loooong время работы с этим "вещами":

BindingModels для привязки данных (mvc или api)

ViewModels для просмотров на mvc (у вас могут быть несколько страниц mvc внутри вашего api, так что хорошо иметь место для этого, это может быть документация, вводная страница, что угодно. Если нет представления, то у вас может быть ноль ViewModels). Одно из преимуществ этого заключается в том, что вы можете в своем представлении /web.config иметь ссылку на пространство имен ViewModels, и это не будет загрязнено вашими ресурсами api.

ResourceModel для ресурсов веб-api. В webapi вложенные ресурсы также являются ресурсами, которые идут в любом месте дерева, которое не так распространено на mvc, поэтому присвоение им ресурсов имеет много смысла.

Если вы хотите получить ресурс, вы можете использовать свою модель ресурсов. Помните, что вы получаете то же самое, что и вы отправляете назад.

Если вам нужна настраиваемая привязка для ввода (это должен быть ваш сценарий по умолчанию), у вас есть свои модели привязки.

Если у вас есть какое-либо представление mvc, для целей администрирования, документации и т.д., используйте ViewModels.

Если у вас есть страница формы на mvc, вы можете использовать свой BindingModel также на контроллере POST. Нет необходимости иметь другую модель для публикации в MVC или WEBAPI. Специально, когда модельное связующее или форматирующий элемент могут понимать и сопоставлять одну и ту же модель привязки с использованием тех же аннотаций данных.

Иногда вы хотите создать модель привязки с ресурсом и некоторыми дополнительными полями. Наследование - ваш друг.

Иногда вы хотите создать модель привязки с более чем одним ресурсом и (необязательно, дополнительные поля). Ресурсы в качестве свойств - ваш друг.

В мире MVC вы также можете использовать концепцию "Ресурс", но это гораздо реже. Это пригодится, когда у вас есть MVC и Web Api в одном проекте.

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

О, и я забыл, что стратегия картографии стоит исследований. Я лично делаю свои собственные сопоставления, но эта логика в одном месте бесценна.

EDIT: Очень наивный пример

ContactViewModel{

    string Name {get;}
    string LastName {get;}
    List<Country> AvailableCountries {get;}
    Country Country {get;}
    bool IsAdmin {get;}

}

ContactBindingModel{

    string Name {get;set;}
    string LastName {get;set;}
    int Country {get;set;}

}

ContactResourceModel{

    string Name { get;set;}
    string LastName {get;set;}
    Country Country {get;set;}
    string IsAdmin {get;}

}

Ответ 3

Если вы пытаетесь создать систему на основе REST, то понятие ViewModel и View может быть очень полезным. Вы можете довольно точно сопоставить понятие Resource с ViewModel и представление View.

Если вы перестанете думать на мгновение о том, как выглядит просмотр на сайте MVC. Это документ HTML. Документ, содержащий кучу семантической информации, заголовка, тела, разделов, абзацев, таблиц и т.д. Он не должен содержать информацию о стиле. Это работа веб-браузера и CSS. Люди путаются, когда начинают думать о HTML как пользовательском интерфейсе. Он не должен быть пользовательским интерфейсом, это содержание пользовательского интерфейса.

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

Ответ 4

В настоящее время мы работаем над аналогичным проектом, который использует ASP.Net MVC и ASP.Net Web Api.

Мы используем ASP.Net MVC для создания глобальной структуры наших страниц. Затем наша реализация MVVM javascript вызывает веб-api для заполнения возвращенных данных в моделях просмотра клиента. Для этого наша api возвращает модель просмотра, которая соответствует ожидаемому интерфейсу.

Я думаю, что ваши модели просмотра api будут отличаться от MVC ViewModels (которые не являются ViewModels с точки зрения MVVM).

Это зависит от вашего использования api. Например, для внутреннего использования вам не всегда нужно избегать отображения вашей модели домена. Таким образом, вы избежите сопоставлять модель в ViewModel и увеличивать производительность. Но в случае, когда вам нужно преобразовать некоторые свойства в ваши модели, viewModels значительно помогут вам структурировать ваш код в связном режиме.

Поскольку в webapi нет представлений, я думаю, что нет смысла иметь параметр ViewModel в качестве параметра.

Я бы сказал, что ваш api потребляется вашими взглядами в конце, имеет смысл иметь ViewModel.

Остается ли на сайте MVC просто плюнуть назад, а затем вы используете JQuery для вызова своего webapi или просто вызываете методы действия MVC, которые непосредственно вызывают те же методы, которые вызовет Webapi?

Это просто вопрос выбора здесь. Вы можете вызвать действие MVC для получения сгенерированных представлений (в html), или вы можете вызвать WebApi для получения ответов JSON/XML, которые затем будут привязаны к вашему javascript-коду в ваших представлениях.

Ответ 5

Просто чтобы добавить то, что говорили другие, полезно использовать для проверки также то, что обычно называют ViewModel. Вы можете пометить свои классы аннотациями данных, включая любые требования проверки. В действиях вашего контроллера вы все равно можете использовать ModelState для принудительного выполнения проверки и возврата соответствующих сообщений через HttpRequestException или просто HttpResponseMessage.