У нас есть решение с несколькими веб-проектами MVC и теперь добавление проекта WebApi, ориентированного на клиента.ASP.NET - одно решение, проекты MVC и WebApi, отдельные модели для каждого?
API будет гораздо более облегченной версией того, что доступно через любой из веб-проектов (хотя с течением времени он, вероятно, будет расширяться гораздо больше), поэтому мы пришли к важному вопросу о том, как для обработки моделей.
Каковы наилучшие методы обработки моделей в разных проектах?
Насколько я понимаю, модель в проекте WebApi будет использовать, например, некоторые атрибуты свойств, которые не имеют смысла для веб-приложения MVC. А также в качестве примера атрибут Display не имеет смысла для WebApi, но очень полезен в представлении.
Это заставляет меня думать, что я должен создавать отдельный набор моделей для WebApi, но также интересно, не хватает ли я чего-то.
Я понимаю, что это может быть вопрос, который может привести к ряду мнений, поэтому я в основном ищут то, что считается передовой практикой в отрасли.
Веб-API обычно используется для веб-сервисов. Это определенно хорошая практика для того, чтобы ваше обслуживание и ваше фактическое приложение были отдельными, поэтому для этого вам следует использовать разные проекты. Если вы хотите, чтобы они разрабатывались независимо, вы также должны разделить решения. – user3038092
Мы уже отделили API от своего собственного проекта - мой вопрос заключается в том, следует ли использовать одну модель среди разных проектов. Создание единой общей библиотеки моделей по сравнению с отдельными для каждого проекта. – McCee
Я бы использовал несколько проектных проектов, каждый из которых предназначался для этого. Таким образом, у вас есть более четкое разделение между сервисом и приложением (и, возможно, база данных). Но вы можете столкнуться с большим количеством кода, создав методы сопоставления, чтобы при необходимости сопоставить одну модель с другой. – user3038092