Зависит от структуры фронтэнда. Если у вас одностраничное приложение построенное на Angular, Durandal, Knockout или других JS фреймворках - тогда, конечно же, следует получать JSON данные из WebAPI напрямую из JS. Если же у вас обычное ASP.NET MVC приложение, то используйте HttpClient. Логику получения данные я бы тоже вынес в отдельный класс, типа XxxRepository с методами Get, Put и т.п., чтобы облегчить код контроллера и абстрагировать репозиторий, если в будущем захочется перенести бэкэнд с WebAPI на что-то другое.
WebAPI должен возвращать сырые данные (Model), рекомендуемо в JSON формате. Клиентская сторона (MVC приложение например) должна принять эти данные, сконвертировать в модель-представление (ViewModel) и дать нужному представлению (View). Так как большинство свойств в Model и ViewModel будут похожи, можно воспользоваться автоматической "конвертацией" объектов, например AutoMapper (https://github.com/AutoMapper/AutoMapper).
В одном из видео на Channel9 разработчики сказали, что стоит ориентироваться на начало 2015 года. Но в принципе, начать разработку можно уже и осенью-зимой, если релиз проекта намечать на следующий год.
Критериев очень много.. Ожидаемое количество пользователей, сложность базы данных (и как следствие - логики), аудитория и так далее.
Если совсем вкратце, то я бы поделил так: если у вас ожидается работа с файлами (обработка изображений, видео и всякое такое) или серьёзными документами, лучше вывести логику работы в WCF сервис. Если же модели данных будут очень простыми (типа твиттера или вообще любой сервис, где вся логика - это CRUD + разные хитрые методы поиска по базе данных) - то выбирайте WebAPI в качестве основы бэкэнда, WCF здесь не нужен и думать больше нужно о выборе базы данных (SQL или NoSQL (графовая или табличная, распределенная или нет.. смотря какая будет нагрузка)).
В этом случае вся логика и работа с данными должна переехать на WCF сервер, который должен быть запущен в режиме Windows сервиса, чтобы позволить бесперебойное выполнение длительных\отложенных задач (в IIS это невозможно). Для скорости и безопасности такой сервис желательно повесить на пайпы (net.pipe endpoint).
WebAPI здесь превратится лишь в прокси слой, доступный извне (на 80\443 порту), осуществляющий аутентификацию запросов и вывоз нужных функций WCF сервера.
Но как я уже сказал, для небольших проектов WCF будет скорее всего лишним. Всё зависит от задачи...
Большая часть бизнес логики, вывернутая наружу как REST API, аутентификация, работа с базами данных (это если нет WCF сервера).
А MVC лишь для отображения объектов пользователю, все операции, меняющие состояние базы данных должны происходить через вызовы REST API.
Вкладка ENDPOINTS в настройках виртуальной машины даёт возможность открыть нужные порты во встроенном Firewall'е Azure. Например, чтобы ваш сайт был доступен извне, необходимо добавить HTTP порт (80) (добавить можно нажав на кнопку ADD на панеле снизу).
Что касается DNS, вам нужно смотреть документацию вашего DNS регистратора. В панеле управления доменом вам необходимо зарегистрировать А запись для вашего домена. Например у GoDaddy панель выглядит примерно так: pbrd.co/1m6SgZ6
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
