Интерфейсы имеют явное преимущество того, чтобы быть "несколько заменяемым в горячем режиме" для классов. Изменение класса от одного родителя до другого будет часто приводить к большой работе, но Интерфейсы могут часто удаляться и изменяться без большого эффекта на класс реализации. Это особенно полезно в случаях, где у Вас есть несколько узких наборов поведения, которое "можно" хотеть, чтобы класс реализовал.
Это работает особенно хорошо в моем поле: игровое программирование. Базовые классы могут быть чрезмерно увеличены в размере с тоннами поведений, которые "могут" быть необходимы наследованным объектам. С интерфейсами различные поведения могут быть добавлены или удалены к объектам легко и с готовностью. Например, если я создаю интерфейс для "IDamageEffects" для объектов, что я хочу отразить повреждение, тогда я могу легко применить это к различным игровым объектам, и легко передумать позже. Скажите, что я разрабатываю начальный класс, который я хочу использовать для "статических" декоративных объектов, и я первоначально решаю, что они ненепрочны. Позже, я могу решить, что это представило бы больший интерес, если они могли бы аварийно завершиться так, я изменяю класс для реализации интерфейса "IDamageEffects". Это намного легче сделать, чем переключение базовых классов или создание новой иерархии объектов.
Я недавно должен был сделать WCF 3.5 REST (webHttpBinding
) сервис доступный и на HTTP и на HTTPS в Microsoft Azure App Service (IIS). Это была забава... и мучительное приключение. Вот мои результаты и мой web.config
<system.serviceModel>
:
Примечание: эти примечания для выполнения веб-сервиса REST WCF с помощью *.svc
(@ServiceHost
) файлы в рамках минимального ASP.NET 4,7 приложения (с Global.asax
) в IIS 10 на Windows Server 2016. Эти примечания не делают , относятся к саморазмещенным сервисам WCF, не-REST сервисы WCF (т.е. SOAP), или платформы, более старые, чем Платформа.NET 4.7. Это также не относится к.NET Core.
<serviceHostingEnvironment>
, элемент важен, удостоверьтесь, что multipleSiteBindingsEnabled="true"
установлен. <baseAddressPrefixFilters>
, которые больше не необходимы. <serviceMetadata>
элемент в Вашем web.config
файл вообще. <endpoint address=""
, атрибуты - просто оставляют атрибут пустым. литий> ул.>необходимо всегда использовать относительные адреса конечной точки для размещенных IIS сервисных конечных точек. Предоставление полностью определенного адреса конечной точки (например, http://localhost/MyService.svc ) может привести к ошибкам в развертывании сервиса, если адрес конечной точки не указывает на приложение IIS, которое размещает сервис, представляющий конечную точку. Используя относительные адреса конечной точки для размещенных сервисов избегает этих потенциальных конфликтов.
web.config
файл говорит WCF принимать Подключения HTTPS, когда хост-приложению (т.е. IIS) не включили HTTPS в его родительском веб-сайте. <services>
элемент быть опущенной и быть автоматически сгенерированной закулисная, однако у меня не было последовательных результатов с УСПОКОИТЕЛЬНЫМИ сервисами с dual-HTTP+HTTPS привязкой, таким образом, я все еще определяю мой <services>
вручную. Вот мой <system.serviceModel>
элемент от моего web.config
файл:
<system.serviceModel>
<services>
<service name="WcfService1.MainService">
<endpoint address="" binding="webHttpBinding" contract="WcfService1.IMainService" behaviorConfiguration="myWebBehavior" bindingConfiguration="myWebHttpBindingInsecure" />
<endpoint address="" binding="webHttpBinding" contract="WcfService1.IMainService" behaviorConfiguration="myWebBehavior" bindingConfiguration="myWebHttpBindingSecure" />
</service>
<service name="WcfService1.AnotherService">
<endpoint address="" binding="webHttpBinding" contract="WcfService1.IAnotherService" behaviorConfiguration="myWebBehavior" bindingConfiguration="myWebHttpBindingInsecure" />
<endpoint address="" binding="webHttpBinding" contract="WcfService1.IAnotherService" behaviorConfiguration="myWebBehavior" bindingConfiguration="myWebHttpBindingSecure" />
</service>
<!-- etc... -->
</services>
<behaviors>
<endpointBehaviors>
<behavior name="myWebBehavior">
<webHttp />
</behavior>
</endpointBehaviors>
<serviceBehaviors>
<behavior>
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
<protocolMapping>
<!-- By default (in machine.config), the 'http' scheme is mapped to 'basicHttpBinding' (SOAP), not 'webHttpBinding' (REST) and the 'https' scheme is not mapped. -->
<add binding="webHttpBinding" scheme="https" bindingConfiguration="myWebHttpBindingSecure" />
<add binding="webHttpBinding" scheme="http" bindingConfiguration="myWebHttpBindingInsecure" />
</protocolMapping>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
<bindings>
<webHttpBinding>
<!-- maxReceivedMessageSize="104857600" is 100MiB -->
<binding name="myWebHttpBindingInsecure" maxReceivedMessageSize="104857600" transferMode="Streamed">
<security mode="None" />
</binding>
<binding name="myWebHttpBindingSecure" maxReceivedMessageSize="104857600" transferMode="Streamed">
<security mode="Transport" />
</binding>
</webHttpBinding>
</bindings>
</system.serviceModel>