Правильно ли переключать клиентскую логику на уровне сервиса?

Question

У нас есть два клиентских приложения (веб-приложение и приложение агента), которые обращаются к методам в одной и той же службе, но с немного различными требованиями. Моя команда хочет контролировать поведение на стороне службы, передав параметр ApplicationType каждому методу - который по сути является перечислением, содержащим имя вызывающего клиентского приложения - который затем используется в качестве ключа для поиска в базе данных для настройки службы специфичные для клиента опции.

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

Что-то не так с клиентским приложением, которое сообщает службе, кто они? Или действительно нет никакой разницы между передачей ключа конфигурации и набором параметризованных опций?

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

Как бы вы это сделали?

Answer 1

В многоуровневом решении вы всегда должны рассматривать свои слои как луковичные слои, а зависимости всегда должны идти внутрь, а не наружу.

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

Если вы не классифицируете клиентов (web, win, wpf, cli) или обобщаете их с помощью профилей клиентов (которые клиентские приложения могут настраивать), я бы никогда не назвал имя вызывающего приложения, так как это может сделать бизнес логический уровень, осведомленный и зависящий от внешнего уровня.

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

Но я бы определенно искал другие пути, прежде чем идти по вашему описанному пути.

Answer 2

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

Answer 3

Это сложная тема для обсуждения без твердого примера.

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

Вот что я бы сделал:

• Просмотрите каждый метод, чтобы увидеть, что должно отличаться и почему.
• Создание разных методов для разных целей. Имя метода должно быть самоочевидным. Если вам когда-либо понадобится нарушить совместимость, у вас будет больше контроля (при условии, что вы не используете систему управления версиями, которая была бы излишней для внутренней службы).
• В некоторых случаях параметры запроса (flags / enum values) являются более подходящими.
• В некоторых случаях знание операционной среды является более подходящим (особенно для защиты данных). Операционная среда почти всегда отправляется во время запроса на вход. Что-то типа «присутствовал» / «защищен» (агент агент) против «без присмотра» / «не защищен» (веб-клиент). Теперь вы должны обменяться ключом сеанса (HTTP cookie или идентификатором сеанса на уровне приложения). Сеансы, очевидно, не работают, если вам нужно на 100% не сохранять состояние - особенно если вы хотите масштабировать без репликации сеанса ... если у вас есть это требование, отправляйте структуру в каждом запросе.

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

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

Вот сценарий, который следует рассмотреть: что, если разрабатывается новый тип клиента, который немного отличается таким образом, что нарушит совместимость с исходным запросом? Теперь у вас есть два запроса. 2 клиента используют запрос A, а 1 клиент использует запрос B. Если вы передаете тип клиента каждому запросу, сервер должен работать для каждого возможного типа клиента. Гораздо сложнее тестировать и поддерживать !!

Answer 4

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

В .net дизайн не чувствует себя таким образом, потому что учетные данные живут в потоке (т.е. когда вы устанавливаете IIPrincipal, эта информация передается в потоке - она ​​передается вместе с каждым вызовом метода, но не параметр.)

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