Основанный на REST сайт MVC и / или WCF

Question

Я знаю, что на самом деле есть ряд вопросов, похожих на этот, но я не смог найти тот, который точно отвечает на мой вопрос.

Я создаю веб-приложение, которое будет

• очевидно отображать данные для пользователей:)
• иметь открытый API для аутентифицированных пользователей, чтобы использовать
• , позже быть перенесенным на мобильные устройства

Итак, язастрял на дизайне.Я собираюсь использовать asp.net MVC для веб-сайта, однако я не уверен, как после этого структурировать свою архитектуру.

Должен ли я:

• сделать сайт RESTful и действоватькак API
  • в моем первоначальном обзоре, GET возвращает полное представление, а не только данные, что, как мне кажется, убивает идею открытого API
  • также, если я действительновыполнять бизнес-логику в моем контроллере?Чтобы иметь возможность масштабирования, не лучше ли иметь отдельный слой бизнес-логики, который находится на другом сервере, или я просто рассмотрю возможность переноса своего сайта MVC на другой сервер, и это решит ту же проблему?Я пытаюсь создать дизайн SOLID , поэтому кажется, что лучше абстрагировать его в отдельный сервис (который я мог бы просто назвать другим классом, но затем я возвращаюсь к проблеме масштабируемости ...)
• сделать сайт не RESTful и создать службу RESTful WCF, которую сайт будет использовать
• сделать веб-сайт и службу WCF спокойными, однако это кажетсяизбыточный

Я довольно новичок в REST, поэтому проблема может заключаться в недоразумении с моей стороны.Надеюсь, я объясню это хорошо, но если нет, пожалуйста, дайте мне знать, если вам нужно что-то разъяснить.

Answer 1

Простые и простые .... было бы проще с точки зрения сложности отделить веб-сайт и ваш API . Это немного чище ИМО тоже.

Однако вот несколько советов, которые вы можете сделать, чтобы облегчить процесс обработки обоих вместе, если вы решите пойти по этому пути. (В настоящее время я делаю это с личным проектом, над которым я работаю)

1. Держите логику вашего контроллера довольно открытой. Судя по тому, что вы хотите сделать его SOLID, вы, вероятно, уже делаете это.
2. Отделите модель, которая возвращается в представление, от фактической модели. Мне нравится создавать модели, специфичные для видов, и иметь возможность преобразовать модель в эту модель, специфичную для вида.
3. Убедитесь, что вы все версии. Возможно, вы захотите разрешить и поддерживать старые запросы API, поступающие в течение достаточно долгого времени ... особенно по телефону.
4. На самом деле используйте REST в полном объеме, а не просто другое имя для HTTP. В большинстве реализаций отсутствует тот факт, что при любом типе ответа состояние должно передаваться вместе с ним (без ST). Разрешить самостоятельное обнаружение действий как на странице, так и в ответах API. Например, если вы разрешаете пейджинг в ресурсе, всегда указывайте API или веб-страницу. На этом есть целая страница википедии. Это очень помогает с развязкой, позволяющей иногда автоматически обновлять клиенты до последней версии.

Теперь действия вашего контроллера будут выглядеть примерно так: псевдокод

MyAction(param) {
    // Do something with param
    model = foo.baz(param)

    // return result
    if(isAPIRequest) {
       return WhateverResult(model)
    }
    return View(model.AsViewSpecificModel())
}

Одна вещь, которую я играл сам с собой, это создание собственного типа ActionResult, который обрабатывает логику возврата, чтобы она не дублировалась на протяжении всего проекта.

Answer 2

Я бы использовал службу REST для вашего сайта, поскольку она не добавит значительных накладных расходов (при условии, что они находятся на одном сервере) и значительно упростит вашу кодовую базу.Вместо двух API: одного частного (в качестве ссылки на DLL) и одного открытого, вы можете «есть свой собачий корм».Единственное предостережение, которое вам нужно проявить, - убедиться, что вы не сгибаете публичный API в соответствии со своими потребностями, а вместо этого используете отдельный частный API, если это необходимо.

Вы можете использовать RestSharp или EasyHttp для вызовов REST внутри сайта MVC.

ServiceStack , вероятно, упростит задачу API, вы можете использовать существующие объекты доменаи просто напишите набор служб, которые получают / обновляют / удаляют / создают объекты без необходимости писать 2 действия для всего в MVC.

Answer 3

Я бы сделал отдельный слой бизнес-логики и слой WCF (успокоительный) поверх этого. Это отделяет ваш BLL от вашего клиента. Вы могли бы даже иметь разные клиенты, использующие один и тот же API (не говоря уже о том, следует ли вам это делать, но это дает вам гибкость). В идеале ваш сервисный слой должен возвращать не ваши доменные сущности, а объекты передачи данных (которые вы можете отобразить с помощью Automapper), хотя это зависит от объема и спецификаций вашего проекта.

Размещение этого на другом сервере делает его другим уровнем, уровнем <>.