Что-нибудь не так с переносом проверки CLI / логики на серверную часть?

Question

У меня есть клиент-серверное приложение.Одним из клиентов является CLI.CLI выполняет некоторую базовую проверку, а затем отправляет SOAP-запросы на сервер.Ответ интерпретируется, и пользователю предоставляется соответствующая информация.Каждая команда включала в себя запрос к веб-сервису.

Каждый раз, когда службы модифицируются на стороне сервера, необходимо выпускать новый CLI.

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

(Даже завершение вкладки может быть выполнено при содействии сервера.)

Я чувствую, что в моем случае это упростило бы разработку и сократило бы объем работ по техническому обслуживанию.

Есть ли подводные камни, которые я упускаю из виду?

Обновить

Проблемы масштабируемости не являются первоочередными.

Answer 1

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

Answer 2

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

Answer 3

Что мне интересно, так это будет ли что-то неправильное в том, чтобы сделать мой CLI невероятно тонким.

...

Я чувствую, что в моем случае это упростило бы разработку и сократило бы объем работ по техническому обслуживанию.

Люди делали это годами, используя telnet / SSH для удаленного взаимодействия с CLI, который работает на сервере.Если все интеллектуальные данные в любом случае должны находиться на сервере, возможно, нет причин для того, чтобы ваш CLI был распределенным клиентом с интеллектуальными данными.Просто пусть это будет терминальный сеанс - если вам сойдет с рук использование SSH, я бы так и сделал - тогда клиентская часть выполняется один раз (или, возможно, просто готовая часть программного обеспечения), и все обслуживание и обновления происходят на сервере (добро пожаловать в 1978).

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

Answer 4

Использование пар имя / значение в строке запроса на самом деле довольно распространено.Однако, в этот момент, зачем вообще беспокоиться о SOAP?Вместо этого просто перейти на спокойную архитектуру?