Добрый день. Помогите разобраться что лучше будет использовать и правильно ли я понимаю предназначения технологий. Чувствую что у меня какая-то каша в голове.
Хочу сделать приложение по трехзвенной архитектуре с использованием EntityFramework. Основным клиентом будет WinForm приложение под .Net. Но есть еще Android приложение, под которое сейчас уже есть WCF сервис, который отдает данные в JSON с помощью реализации методов типа: Stream Metod1(string param1)
Пробовал использовать WCF Data Service, и с его помощью по сути я проксирую dbContext Entity Framework на клиент. Все хорошо, но это как-то больше предполагает реализацию бизнес-логики на стороне клиента? А хотелось бы все же бОльшую ее часть делать в сервисе (ну например, что бы использовать ее для Android клиента). Или я не прав?
Да, можно добавить в сервисе метод


И потом вызвать его на клиенте


Это нормальный подход для WCF Data Service? Особенно для случая, когда я хочу возвращать наборы каких-то сущностей.

Что очень понравилось в нем, так это случай когда бизнес логике нет, и нужен по сути обычный CRUD. 1 строчка кода и Грид заполнен данными:


2 строчка и все изменения в гриде (вставка, обновление, удаление) сохранились в базу:


Такой функционал тоже был бы иногда очень полезен. Не представляю как это можно было бы реализовать через обычный WCF. Во всяком случае сопоставимо простым образом. Или я ошибаюсь?

Почитал эту статью http://rsdn.org/article/ms/Internet_Applications_Microsoft.xml#E2F
Хоть она и устаревшая и WCF RIA с Silverlight уже не актуальны, но что тогда пришло на их замену, что бы взять в себя лучшее из WCF Data Service и просто WCF? Или я хочу чего-то странного пытаясь скрестить WCF Data Service и просто WCF?
И еще вопрос про WCF Data Service: правильно ли я понимаю что но может быть только Statless и никаких данных между вызовами хранить в себе не может в отличии от WCF? И аналога CallBackContract для .Net клиента что бы реализовать дуплексную связь между клиентом и сервисом тут тоже быть не может?