Мое предложение после того, как займет слишком много времени, работая с этой 'вещи':
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;}
}
Ya это одна из причин, почему я не люблю положить свои аннотации на самой EF. Думаю, я должен использовать viewModel, но просто называть его чем-то другим DataModel? Я все еще не понимаю, как будет работать весь сайт. Например, у меня будет метод Add. Мобильные устройства и веб-сайт могут добавить. Должен ли сайт MVC вызывать метод webapi? В этом случае это имеет смысл. Но как насчет Edit Case на мобильном телефоне снова, кажется, имеет смысл называть webapi, но на сайте кажется, что вы предпочитаете использовать mvc, чтобы получить обратную ссылку, которая привязана, а затем вернуться к этому представлению. – chobo2
Я столкнулся с той же проблемой, и решение, к которому я пришел, состоит в том, что не имеет смысла использовать мой сайт на MVC для отправки/получения данных и использования WebApi для других (отправляемых с сайта MVC). Основное преимущество WebApi заключается в том, чтобы позволить внешним активам напрямую использовать ваши данные/бизнес-правила через API. Если у вас уже есть сайт MVC в том же проекте, зачем заставлять его проходить через WebApi для взаимодействия с вашим доменом, если вы можете напрямую использовать MVC? И я согласен, что несколько другое изменение имени сделает его более ясным. InputModel? RequestModel? Это просто терминология, и на самом деле это то же самое. –
Я предполагаю, что вы создадите отдельный проект для своего сайта mvc и получите его в том же решении, что и webapi. Я знаю, что у webapi могут быть контроллеры mvc, но я думаю, что это больше похоже на то, что вы показываете документацию и тому подобное о вас api для пользователя. – chobo2