Разработка нового УСПОКОИТЕЛЬНОГО веб-сервиса в.NET — где я должен начать? ASP.NET-MVC, WCF?
Цель состоит в том, чтобы создать сервис, который я затем использую с помощью jQuery и основанного на стандартах веб-фронтенда, мобильное устройство "толстые клиенты" и очень вероятно настольное приложение WPF.
Кажется, что WCF был бы хорошим вариантом, но я никогда не создавал УСПОКОИТЕЛЬНЫЙ сервис с WCF, таким образом, я не уверен, где даже начать на том подходе.
Другая опция, о которой я думаю, использует ASP.NET, MVC, добавляя некоторые пользовательские маршруты, добавляют несколько действий контроллера и использующий различные взгляды для выставления JSON, xml, и других типов возврата.
Этот проект является главным образом осуществлением изучения для меня, и я хотел бы провести некоторое дополнительное время, и сделать его правильно так у меня есть лучший undertanding того, как части совмещаются.
Таким образом, мой вопрос - это, какой подход я должен использовать для создания этого УСПОКОИТЕЛЬНОГО сервиса, и каковы некоторые преимущества выполнения его тот путь?
3 ответа
Обычно я бы сказал WCF для любого типа размещенного сервиса, но в конкретном случае для сервисов RESTful, использующих JSON в качестве механизма сериализации, я предпочитаю ASP. NET MVC (далее я буду называть его ASP.NET).
Одна из первых причин - механизм маршрутизации. В WCF вы должны определить это в контракте, что хорошо, но если вам нужно быстро внести изменения в свою маршрутизацию, с моей точки зрения, это намного проще сделать, используя механизм маршрутизации в ASP. СЕТЬ.
Кроме того, как указано выше, если у вас есть несколько служб, представленных через несколько интерфейсов в WCF, трудно получить полное изображение структуры URL-адресов (что важно), тогда как в ASP.NET у вас (обычно) есть все назначения маршрутов в одном месте.
Вторая особенность ASP.NET заключается в том, что у вас будет доступ ко всем внутренним объектам, которыми известен ASP.NET (запрос, ответ, сервер и т. Д.), Что важно при раскрытии HTTP -конкретная конечная точка (которую вы создаете). Конечно, вы можете использовать многие из этих же вещей в WCF, но вы должны специально сообщить WCF, что вы это делаете, а затем разрабатывать свои службы с учетом этого.
Наконец, на собственном опыте я обнаружил, что DataContractJsonSerializer не слишком хорошо обрабатывает значения DateTimeOffset , и это тип, который вам следует использовать вместо DateTime при работе со службой (через любую конечную точку), которая может быть вызвана людьми в нескольких часовых поясах. В ASP.NET есть другой сериализатор, который вы можете использовать, или, если хотите, вы можете создать свой собственный ActionResult , который использует для вас настраиваемый сериализатор. Лично я предпочитаю сериализатор JSON.Net .
Одна из приятных особенностей сериализатора JSON.Net и ASP.NET, которая мне нравится, заключается в том, что вы можете использовать с ними анонимные типы, если вы умен. Если вы создаете статический универсальный метод для неуниверсального типа, который затем делегирует внутренний универсальный тип, вы можете использовать вывод типа, чтобы легко использовать анонимные типы для ваших сериализованных возвращаемых значений (при условии, что они одноразовые, конечно, если вы иметь структуру, которая возвращается последовательно, вы должны ее определить и использовать).
Также следует упомянуть, что вам не нужно полностью сбрасывать со счетов WCF при разработке службы RESTful. Если вы выталкиваете канал ATOM или RSS из своей службы, тогда классы в пространстве имен System.ServiceModel.Syndication из Massive помогают в создании и сериализации этих каналов.Создание простого подкласса класса ActionResult для получения экземпляра SyndicationFeed и последующей его сериализации в выходной поток при выполнении ActionResult довольно просто.
Вот мысль, которая может помочь вам сделать выбор между ASP.NET MVC и WCF. . Ожидаете ли вы, что в описываемых вами сценариях потребуется использовать протокол, отличный от HTTP?
WCF не зависит от транспортного протокола и поэтому сильно отличается от ASP.NET. У него есть каналы и привязки, сообщения, сервисные контракты, контракты данных и поведения. Когда дело доходит до создания распределенных приложений, он дает очень мало руководящих указаний. Это дает вам чистый лист для дальнейшего развития.
ASP.Net MVC, естественно, является фреймворком на основе Http.Он имеет дело с HTTP-командами, типами мультимедиа, URL-адресами, заголовками ответов и заголовками запросов.
Вопрос в том, какая модель ближе к тому, что вы пытаетесь построить?
Теперь вы упомянули ReST. Если вы действительно хотите создавать свои распределенные приложения в соответствии с ограничениями ReST, вам лучше начать с OpenRasta. Он проведет вас по этому пути.
Вы можете делать Rest в ASP.Net MVC и можете делать это в WCF, но с этими решениями вы не попадете в яму успеха ;-)
Лично я не в восторге от реализации REST сервисов в WCF. Я считаю, что фреймворк asp.net mvc является более естественной моделью программирования для этого.
Исполнитель http://atomsite.net/ первоначально реализовал спецификацию atompub в WCF, а затем переписал весь сервис, используя asp.net mvc. Его опыт повторил мой комментарий выше, что для чистого REST-сервиса asp.net mvc - это то, что нужно.
Единственным исключением было бы, если бы я хотел потенциально раскрыть сервис в restful и non restful способах. Или если бы я раскрывал существующую службу WCF через REST.