Microsoft ASP .NET Web API, MVC 4 и архитектура SPA
Недавно Microsoft выпустила бета-версию MVC 4, в которой есть такие новые очень приятные функции, как Web API и SPA. И, как всегда, демонстрации Microsoft не демонстрируют лучшие практики с точки зрения дизайна программного обеспечения. Например, используя DbController, который тесно связан с EF.
Мне кажется, что SPA и Web API идут рука об руку в современном приложении ASP .NET. Я хотел бы услышать любые предложения по структурированию решения на основе MVC 4, которое собирается применять эти новые технологии, такие как Web API и SPA.
Например, целесообразно ли разделять проект Web API с собственными контроллерами вне базового проекта MVC4 или нет. Как бороться с SPA и не использовать DbController для того, чтобы хранить постоянство данных отдельно? Что будет главной ролью обычного приложения MVC4 и особенно Razor?
Любые другие мысли или предложения высоко ценятся.
2 ответа
О разделении MVC4 + Web API: imho (как всегда) зависит от вашего конкретного проекта.
Что касается EF: вам определенно не следует возвращать EF Entities, а вместо этого возвращать свои собственные DTO.
Роль бритвенных представлений MVC может заключаться в визуализации частичных представлений, которые вы динамически загружаете из клиента. Вы также можете сделать некоторые вещи, такие как условная загрузка CSS / JS и т. Д. Для начальной страницы загрузки индекса.
Я думаю, что это хорошая идея - хранить API в отдельном проекте веб-сайта от вашего SPA/ веб-сайта, так как вы можете столкнуться с проблемами с жадными маршрутами.
Обязательно держите свой доступ к данным отдельно и слабо связаны.