Привет всем!

Народ подскажите, плиз, как по вашему наиболее правильно организовать контракт WCF-службы:
1. Одна функция (например "Execute"), которой в качестве параметра передается идентификатор действия, которое нужно выполнить и список параметров, необходимых для выполнения этого действия.
2. Для каждой сущности на сервере свой контракт службы, для каждого действия свою функцию.

В принципе можно и так и сяк, и работать будет. Но наверняка есть рекомендации "ведущих сервисоводов" .
Интересует с точки зрения производительности, масштабируемости (количество сущностей, с которыми придется работать заранее не известно, количество пользователей тоже заранее известно довольно слабо).

Надеюсь, что правильный ответ зависит не только от религиозных убеждений...

Здравствуйте, Аноним, Вы писали:

А>Привет всем!

А>Народ подскажите, плиз, как по вашему наиболее правильно организовать контракт WCF-службы:
А>1. Одна функция (например "Execute"), которой в качестве параметра передается идентификатор действия, которое нужно выполнить и список параметров, необходимых для выполнения этого действия.
А>2. Для каждой сущности на сервере свой контракт службы, для каждого действия свою функцию.

А>В принципе можно и так и сяк, и работать будет. Но наверняка есть рекомендации "ведущих сервисоводов" .
А>Интересует с точки зрения производительности, масштабируемости (количество сущностей, с которыми придется работать заранее не известно, количество пользователей тоже заранее известно довольно слабо).

А>Надеюсь, что правильный ответ зависит не только от религиозных убеждений...


Советую почитать очень хорошую книгу по WCF. После прочтения многое станет очевидным

Здравствуйте, rinat.mergenbaev, Вы писали:

RM>Советую почитать очень хорошую книгу по WCF. После прочтения многое станет очевидным
Большое спасибо! Книга действительно хорошая. Она сейчас у меня на столе. Только я пока прочел ее далеко не всю. Читаю...
Но в ней ответ на свой вопрос не нашел.
Откровенно говоря, мне кажется, что это вопрос вообще не столько по WCF, сколько по архитектуре. Потому как у каждого из вариантов есть свои плюсы и минусы. Просто хочется знать, где их больше.
Или я что-то не так понимаю?

Здравствуйте, Аноним, Вы писали:

А>Привет всем!

А>Народ подскажите, плиз, как по вашему наиболее правильно организовать контракт WCF-службы:
А>1. Одна функция (например "Execute"), которой в качестве параметра передается идентификатор действия, которое нужно выполнить и список параметров, необходимых для выполнения этого действия.
А>2. Для каждой сущности на сервере свой контракт службы, для каждого действия свою функцию.

А>В принципе можно и так и сяк, и работать будет. Но наверняка есть рекомендации "ведущих сервисоводов" .
А>Интересует с точки зрения производительности, масштабируемости (количество сущностей, с которыми придется работать заранее не известно, количество пользователей тоже заранее известно довольно слабо).

А>Надеюсь, что правильный ответ зависит не только от религиозных убеждений...

По сути, интерфейс, торчащий в виде wcf-го эндпоинта — это реализация паттерна фасад. Сколько фасадов нужно — столько эндпоинтов и делай. Исходя из этого первый вариант плох, потому что предоставляет один довольно размытый контракт, а второй плох потому, что предоставляет слишком детализированный контракт (к тому же о накладных расходах на каждый вызов тоже не стоит забывать). Так что истина где-то посередине, я обычно стараюсь делать по одному эндпоинту (с соответствующим контрактом) на каждый тип клиента, который будет подключаться к сервису.

Здравствуйте, Аноним, Вы писали:

А>Привет всем!

А>Народ подскажите, плиз, как по вашему наиболее правильно организовать контракт WCF-службы:
А>1. Одна функция (например "Execute"), которой в качестве параметра передается идентификатор действия, которое нужно выполнить и список параметров, необходимых для выполнения этого действия.
А>2. Для каждой сущности на сервере свой контракт службы, для каждого действия свою функцию.

А>В принципе можно и так и сяк, и работать будет. Но наверняка есть рекомендации "ведущих сервисоводов" .
А>Интересует с точки зрения производительности, масштабируемости (количество сущностей, с которыми придется работать заранее не известно, количество пользователей тоже заранее известно довольно слабо).

А>Надеюсь, что правильный ответ зависит не только от религиозных убеждений...

однозначно 2й иначе для любого приложения можно сделать один огромный метод с сотней параметров на все случаи жизни. Где можно применить 1й вариант, вообще не понятно. К чему этот ущербный минимализм?

А>1. Одна функция (например "Execute"), которой в качестве параметра передается идентификатор действия, которое нужно выполнить и список параметров, необходимых для выполнения этого действия.
А>2. Для каждой сущности на сервере свой контракт службы, для каждого действия свою функцию.

Первый вариант — однозначно нет.
Второй — без фанатизма. Для каждого действия своя операция, а объединение операций в контракты — это уж как спроектируешь. Как говорили выше, сервис — это фасад. Кстати, в упомянутой книжке в конце есть небольшой раздел "best practices", который отвечает на многие вопросы.

Здравствуйте, Аноним, Вы писали:
использую 1й вариант так как операции всего 4 -CRUD а сущностей более 300 — нет смысла плодить на каждую сущность свой контракт если в нем необходимо указать идентификатор операции а параметры передать при помощи xml

Здравствуйте, Аноним, Вы писали:

А>операции всего 4 -CRUD а сущностей более 300 — нет смысла плодить на каждую сущность свой А>контракт
Контракты надо создавать не на сущность, а на workflow.
В противном случае WCF-сервис превращается в фасад для DAL без строгой типизации, а логика workflow переносится на клиента.

Фасад для DAL без строгой типизации уже есть — это SQL-сервер. Перенос бОльшей части логики workflow на клиента лишает сервер приложений смысла существования, потому что ее придется повторить на каждом клиенте.

Здравствуйте, HowardLovekraft, Вы писали:
HL>Контракты надо создавать не на сущность, а на workflow.
HL>В противном случае WCF-сервис превращается в фасад для DAL без строгой типизации, а логика workflow переносится на клиента.
у нас вся логика в DAL — сервис принимает 3 параметра — тип операции, имя сущности и параметры в виде xml-поля, DAL запрашивает у SQL сервера параметры CRUD процедур и и парсит xml раскидывая значения по соответствующим параметрам. Никакой логики на клиенте!

Здравствуйте, Аноним, Вы писали:

А>у нас вся логика в DAL
Это понятно... Не понятно, зачем нужен такой сервер приложений.
Если у вас хранилище — реляционное, то фактически, вы написали XML-обертку над языком SQL. Смысл?

Здравствуйте, HowardLovekraft, Вы писали:

HL>Здравствуйте, Аноним, Вы писали:

А>>у нас вся логика в DAL
HL>Это понятно... Не понятно, зачем нужен такой сервер приложений.
HL>Если у вас хранилище — реляционное, то фактически, вы написали XML-обертку над языком SQL. Смысл? :???:

А смысл майкрософту популяризировать все эти ADO.NET Data Services/REST и т.п.? То же самое по сути, убогенькая надстройка над моделью, которой в 99.9% случаев будет являться слепок какой-нить базы данных.

Здравствуйте, baranovda, Вы писали:

B>То же самое по сути
То же, да не то.
WCF Data Services обеспечивают очень даже строго типизированный доступ к данным и рассматривают данные в объектном представлении, а не в реляционном.
А наш анонимный коллега, насколько я его понял, имеет в виду примерно такой вариант:

public interface IDataService
{
  void Execute(OperationType opType, String entityName, String operationParams);
}
...
String operationParams = ...;
dataService.Execute(OperationType.Insert, "Customers", operationParams);
...

, где
operationParams — нечто вроде:

<Params>
<Param Name="id" Type="Int32">1</Param>
<Param Name="name" Type="String">John</Param>
</Params>

а реализация сервиса генерирует SQL вида:

INSERT INTO CUSTOMERS VALUES(1, 'John');

Помимо минусов, связанных с отловом кучи мелких ошибок в рантайме из-за передачи "Custmoers" в место "Customers" и т.д., развлечения ради предлагаю выполнить LINQ к этому сервису.

Вот типизированный фасад к данным, с LINQ и всеми прочими цацками — бывает востребован, да. Но руками его делать — не приведи боги, особенно когда сущностей — сотни. Собственно, WCF Data Services как раз от этой рутины избавляет.

Но он каг бэ уже написан. Зачем изобретать велосипед?

Здравствуйте, HowardLovekraft, Вы писали:

вот до этого места вы были правы, а тут — нет — я не генерю sql строку — я получаю метаданные о параметрах sp-шки и заполняю их значениями из xml

HL>а реализация сервиса генерирует SQL вида:
HL>

HL>INSERT INTO CUSTOMERS VALUES(1, 'John');
HL>

HL>Помимо минусов, связанных с отловом кучи мелких ошибок в рантайме из-за передачи "Custmoers" в место "Customers" и т.д., развлечения ради предлагаю выполнить LINQ к этому сервису.

Здравствуйте, HowardLovekraft, Вы писали:


HL>Контракты надо создавать не на сущность, а на workflow.
HL>В противном случае WCF-сервис превращается в фасад для DAL без строгой типизации, а логика workflow переносится на клиента.

HL>Фасад для DAL без строгой типизации уже есть — это SQL-сервер. Перенос бОльшей части логики workflow на клиента лишает сервер приложений смысла существования, потому что ее придется повторить на каждом клиенте.

Поясни, пожалуйста, на примере. Трудно понять, что подразумевается под workflow.

Здравствуйте, IluhaA, Вы писали:

IA>Поясни, пожалуйста, на примере. Трудно понять, что подразумевается под workflow
Некоторый техпроцесс. "Работа с заказами", "Ценообразование", "Инвентаризация" и т.п.

Каждая операция в контракте соответсвует какому-либо этапу техпроцесса.
В рамках операции выполняется какой-то кусок бизнес-логики, общий для всех клиентов.
Он может работать с произвольным набором сущностей, затрагивать хранилище, другие сервисы.
Это то, ради чего создается сервер приложений.

Простой пример. Сохранение измененного заказа в ресторанном фронт-офисе приведет к:
1) проверке прав текущего юзера на сохранение заказа;
2) сохранению собственно заказа в базе (сущность №1);
3) сохранению новой позиции заказа в базе (сущность №2);
4) пересчету примененных скидок (сущность №3);
5) отправке данных в систему аудита (обращаемся к другому сервису);
6) постановке в очередь блюда на приготовление (сущность №4);
7) печати бумажки-заказа на кухонный принтер (обращаемся к другому сервису).

Пункты 1-7 — это бизнес-логика. В контракте сервиса — одна операция:

Order UpdateOrder(Order order);

вместо шести. И безразлично, какой клиент подключается к этому сервису — мобильный на наладоннике или стационарный на PC-терминале. Логика сохранения заказа для них будет работать одинаково.

З.Ы. Примеры, конечно, условны.

Здравствуйте, HowardLovekraft, Вы писали:


HL>Пункты 1-7 — это бизнес-логика. В контракте сервиса — одна операция:
HL>

HL>Order UpdateOrder(Order order);
HL>

HL>вместо шести. И безразлично, какой клиент подключается к этому сервису — мобильный на наладоннике или стационарный на PC-терминале. Логика сохранения заказа для них будет работать одинаково.

А почему метод UpdateOrder возвращает опять же Order ?

Здравствуйте, IluhaA, Вы писали:

IA>А почему метод UpdateOrder возвращает опять же Order ?
Если у сущностей есть identity или calculated-свойства (например, код или итоговая сумма), то их значения обновляются после выполнения операций вставки/обновления. При необходимости продолжать работу с графом объектов на клиенте, таким образом можно получить изменения в значениях identity/calculated-свойств без выполнения дополнительных операций.