Отправка запросов от клиента в службу WCF

Question

Я хотел бы, чтобы вы взяли на себя следующее.

Мы рассматриваем SOA как решение некоторых концептуальных проблем, которые у нас есть. Мы не хотим строить одну и ту же логику несколько раз. Поэтому вы хотите создать некоторые сервисы WCF и иметь разных клиентов для получения данных через эти сервисы (возможно, даже приложения Apple). Идеальная ситуация заключается в том, что клиенты настолько тонки, насколько это возможно, их заботит только презентация. Вся бизнес-логика и доступ к данным должны быть устранены в службах WCF.

Теперь мой начальник изучил это, и его самое большое беспокойство в основном в том, что мы впали в хаос. Он предположил, что мы будем определять новый метод для каждого запроса, который мы хотим выполнить в базе данных, грубо говоря.

Так как:

• RetrieveCustomerById
• RetrieveCustomerByName
• RetrieveCustomerByStoreId
• RetrieveCustomerWithPersonalDetailsButWithoutAddressById
• и т.д ...

Таким образом, его идея состоит в том, чтобы клиенты строили запросы и отправляли их службам WCF. Службы WCF выполняют запросы, применяют бизнес-логику и возвращают результаты.

Мне очень интересны все доводы "против" или "за", которые вы, ребята, можете придумать. Заранее спасибо, что подумали со мной.

Answer 1

Ваш босс, вероятно, прав, это то, на что он более или менее похож, но

• Прежде всего, что обязательно с ним не так (хотя читайте до конца, как некоторые из нихне имеет смысла)?
• Не будет RetrieveCustomerWithPersonalDetailsButWithoutAddressById, поскольку CustomerWithPersonalDetailsButWithoutAddress - это другая модель предметной области.
• Передача запросов в бизнес-логику очень напоминает старые времена, когда впараметры интерфейсов, определяемые как object (или если вам столько же лет, сколько мне Variant в VB6 COM).Это означает, что мы не хотим тратить усилия и принять на себя задачу понимания нашего домена. .
• RetrieveCustomerByStoreId не потребуется, поскольку, если он связан с магазином, онответственность хранилища хранилища за его предоставление.

В общем, если вы будете следовать DDD, передача запроса просто сделает дизайн очень небрежным.

Answer 2

Думали ли вы использовать WCF Data Service?http://msdn.microsoft.com/en-us/library/cc668794.aspx

Answer 3

Это сервис WCF в стиле SOAP? Или RESTful один?

В любом случае, у меня возникнет соблазн иметь набор необязательных параметров, с помощью которых вы можете сделать запрос, поэтому, взяв в качестве примера службу RESTful, у вас будет набор дополнительных параметров строки запроса для извлечения клиентов с помощью .

например:.

/ Клиенты? ID = ID / Customers? Имя = NAME / Customers? StoreID = STORE / Customers? ID = ID & withPersonalDetails = истина & withPersonalDetails = ложь

конечно, если вы получаете преимущественно по ID, то

/ Клиенты / {ID} /

будет хорошим URL службы.

Эквивалентные вещи будут работать на стороне SOAPy, с кучей обнуляемых параметров в запросе.

Преимущество будет состоять в том, что клиент должен будет знать только то, что он знает о клиенте, и может просто предоставить это службе, которая может решить более сложную задачу - выяснить, каким должен быть запрос, прежде чем запрашивать клиента. Недостатком было бы то, что клиент мог бы создавать запросы, которые не предоставили достаточно информации, чтобы получить клиента.

Но, по крайней мере, вам не придется беспокоиться о клиенте, предоставляющем неправильные запросы.

EDIT:

Что касается , почему плохая идея иметь клиента, предоставляющего запросы - краткий ответ: "он нарушает инкапсуляцию и вводит множество сцеплений " , Длинный ответ заключается в том, что клиент теперь зависит от деталей реализации сервиса. Скажем, меняется структура базы данных, в идеале вы хотите изменить как можно меньше - в хорошо инкапсулированной системе вам придется обновить слой персистентности и, возможно, больше ничего. Если ваш клиент должен понимать схему, вы должны полностью обновить все слои, что явно плохо.

Во-вторых, если клиент предоставляет запросы, вы безоговорочно доверяете клиенту - у вас есть большая задача ограничить то, что может сделать клиент - подумайте, что произойдет, если кто-то начнет выдавать себя за вашего клиента и запускать произвольно запросы к вашей базе данных - eek!

В-третьих, если вам нужно исправить запрос, если он находится в клиенте, вы должны обновить клиентский код и отправить обновление всем клиентам (а некоторые могут его не принять, оставив этих пользователей с ошибкой), если он инкапсулирован в сервисе вам нужно только решить проблему там.

В-четвертых, где теперь применяются ваши бизнес-правила? В клиенте. Благодаря услуге между клиентом и базой данных все ваши бизнес-правила находятся в одном месте, которое вы прекрасно контролируете.

Фактически, если ваш клиент обрабатывает запросы к базе данных, он также может быть напрямую подключен к базе данных - что хорошо во многих случаях. Но если вы хотите иметь возможность абстрагировать доступ к базе данных за службой, обновлять / исправлять свои бизнес-правила в одном месте и ограничивать вашу ответственность от злонамеренных клиентов, тогда это действительно плохая идея.

(Я уверен, что есть десятки других причин, это от моей головы, до моей утренней чашки чая.)

Answer 4

Таким образом, его идея состоит в том, чтобы клиенты строили запросы и отправляли их службам WCF.Службы WCF выполняют запросы, применяют бизнес-логику и возвращают результаты.

Он называется Specification Pattern и часто используется в DDD.

Одного сервисного метода, который принимает параметр спецификации, достаточно для обработки 95% запросов объекта.

EntityQuery класс в WCF RIA Services является примером того, как можно использовать шаблон спецификациив архитектуре клиент-сервис.