Если вам нужен только тонкий слой CRUD, представленный в виде веб-службы (для обеспечения доступа к базе данных без VPN и т. Д.), То вы можете сделать то же самое, используя Службы данных WCF без всех усилия, и есть нечто более гибкое (например, вы можете написать Linq для прокси).
То, что вы называете сервисным слоем , должно предоставлять доменные объекты , поэтому при условии, что у вас есть модель домена и вы хотите показать ее с помощью веб-службы WCF (REST или иным образом) ), ответы на ваши вопросы:
WCF очень быстрый. Это, очевидно, не прозрачно , но по опыту, если вы подключаетесь к сервисам через сетевое соединение, то любая «медлительность», которую вы испытываете, будет связана с ограничениями задержки / пропускной способности самой сети. Единственным исключением является время установки клиента WCF (то есть канала) - поэтому вы обычно хотите поддерживать их как можно дольше, они не являются одноразовыми объектами, такими как DataContext.
Перегрузка метода не поддерживается по проводам. Вы можете перегрузить методы в сборке службы и дифференцировать их с помощью атрибута OperationContract (и, в частности, свойства Name, но для внешнего клиента они будут выглядеть как разные веб-методы с разными именами.
Однако , если вы разрабатываете веб-сервисы, даже сервисы REST, самое первое, что вам нужно сделать, - это изменить свою перспективу с RPC-мышления («функции») на основанный на документе ("сообщение"). Другими словами, вместо того, чтобы иметь 4 метода, которые принимают разные комбинации из 4 возможных аргументов, вы должны определить класс «request», который предоставляет все 4 из этих параметров в качестве свойств. Это часто считается плохим дизайном для "локального" кода, но это хороший дизайн для веб-сервисов.
В том же духе использование веб-службы для представления «хранилища» обычно считается анти-шаблоном (за исключением служб данных WCF, которые служат совсем другой цели). Причина в том, что веб-сервис должен обеспечивать бизнес-логику (что, как я полагаю, и делает ваш сервисный уровень). Он должен обеспечивать очень грубые операции, атомарные транзакции, когда клиент предоставляет всю информации, необходимой для выполнения одной полной транзакции в одно и то же время, вместо вызова нескольких методов подряд.
Другими словами, если вы обнаружите, что при попытке перевести ваши сервисы в веб-сервисы необходимо вызвать несколько операций над несколькими различными сервисами, чтобы выполнить одну «единицу работы», то вам следует подумать о редизайне. услуги по предоставлению лучших абстракций над работой. Общий дизайн должен сводить к минимуму «болтовню» между клиентом и обслуживанием.
Итак, подведем итог: для вас, вероятно, не имеет большого смысла иметь "уровень обслуживания", который живет на клиенте и который взаимодействует с "уровнем данных", который отображается как веб-служба, , если вы необходимо решить очень специфическую проблему обеспечения CRUD-операций по глобальной сети. С архитектурной точки зрения имеет смысл больше смысла в том, чтобы представить действительные службы через WCF и перейти к более тонким приложениям для клиентов.
Имейте в виду, однако, что переход по пути "SOA", хотя он может иметь много долгосрочных преимуществ, может вызвать некоторую кратковременную боль. В основном у вас есть другая библиотека для обслуживания, другая библиотека для тестирования, другая точка отказа, другая вещь, которую вам нужно документировать. Если у вас нет большой распределенной архитектуры или вы планируете это в ближайшем будущем, то может быть слишком рано начинать интеграцию служб WCF за рамки инфраструктуры служб данных WCF, упомянутой выше.
Кроме того, вы не указываете домен или тип разрабатываемого приложения, но REST в качестве модели конкретного сервиса налагает ряд компромиссов в отношении безопасности, распределенных транзакций и т. Д. Если эти сервисы предназначенные для внутреннего потребления или потребления B2B - т. е. если они являются «корпоративными» сервисами, - вам действительно стоит рассмотреть SOAP, который дает вам доступ к WS-Security, интеграции с Active Directory и всем этим хорошим вещам. REST отлично для общедоступных приложений и гибридных приложений, но не подходит для каждого сценария.