Мы ведем некоторые дискуссии об использовании WCF, создании сервисов и поддержке клиентов.
В настоящее время мы поддерживаем клиента Silverlight, предоставляя версии Silverlight наших клиентских библиотек сервисов, чтобы мы могли строго контролировать тип нашего контракта на обслуживание, который определяется с помощью интерфейсов.
Это нормально, но наличие службы, определенной с помощью интерфейсов, делает ее неудобной для других клиентов, поскольку WSDL имеет много методов, возвращающих ArrayOfAnyType, и все это просто объекты на стороне клиента (которые могут быть преобразованы в правильный тип, но как я уже сказал, это неловко).
Мы могли бы переписать наши сервисы для использования явных DTO для передачи сообщений и воссоздать наши бизнес-объекты, используя аналогичные клиентские библиотеки, что сделало бы наш сервис намного более совместимым.
Хотя это, похоже, блокирует некоторые опции для нас, такие как использование EntityFramework и сущностей самоконтроля, которые он предоставляет, поскольку для них требуется, чтобы одни и те же библиотеки использовались на клиенте и сервере и не были совместимы (поправьте меня, если я мы неправильно поняли)
Кажется, что существует компромисс между функциональной совместимостью и доступом к большему количеству функций из коробки, что позволяет быстрее разрабатывать решения.
Так что мой вопрос в том, какие преимущества мы получаем, решив не взаимодействовать и поддерживать только клиентов .net и silverlight (если поддержка клиентов silverlight может считаться не совместимой)? И какие полезные функции .net мы блокируем, решая, что они совместимы?
Существуют ли стандартные методы, позволяющие сосуществовать обоим типам решений, чтобы вы могли поддерживать клиенты .net, используя весь спектр доступных вам функций, но при этом хорошо поддерживая других клиентов, не входящих в .net?