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

мое предложение после того, как слишком много времени работе с этим 'вещи':

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

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

ResourceModel для ресурсов Web api. В webapi вложенные ресурсы также являются ресурсами, которые идут в любом месте дерева, что не так часто встречается на mvc, поэтому их имена ресурсов имеют большой смысл.

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

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

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

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

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

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

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

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

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

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

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;}

}

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

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

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

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

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

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

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

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

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

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

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

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