CLI 검증/논리 서버측 이동에 문제가 있습니까?

Question

클라이언트/서버 응용 프로그램이 있습니다.클라이언트 중 하나는 CLI입니다.CLI는 몇 가지 기본 유효성 검사를 수행한 다음 서버에 SOAP 요청을 보냅니다.응답이 해석되고 관련 정보가 사용자에게 표시됩니다.모든 명령에는 웹 서비스에 대한 요청이 포함됩니다.

서비스가 서버 측에서 수정될 때마다 새로운 CLI가 출시되어야 합니다.

제가 궁금한 것은 CLI를 엄청나게 얇게 만드는 데 문제가 있는지 여부입니다.수행할 작업은 명령 문자열을 서버로 보내는 것뿐입니다. 그곳에서 유효성 검사, 해석 및 응답 문자열이 반환됩니다.

(TAB 완성도 서버의 협조로 이루어질 수 있습니다.)

제 경우에는 이렇게 하면 개발이 단순화되고 유지 관리 작업이 줄어들 것이라고 생각합니다.

내가 간과하고 있는 함정이 있나요?

업데이트

확장성 문제는 우선순위가 높지 않습니다.

Answer 1

이건 정말 취향의 문제인 것 같아요.검증은 어딘가에서 이루어져야 합니다.당신은 소프트웨어의 복잡성과 클라이언트의 복잡성을 교환하는 것입니다.이것이 반드시 아키텍처에 나쁜 것은 아닙니다.실제로는 발신자에게 기존 서비스에 액세스할 수 있는 대체 수단을 제공하는 추가 서비스를 제공하는 것뿐입니다.내가 조심해야 할 유일한 함정은 코드 복제입니다.CLI 검증이 일부 서비스(예: 숫자 구문 분석)와 동일한 작업을 수행하는 경우 중복을 피하기 위해 리팩터링하십시오.

Answer 2

일반적으로 괜찮을 것입니다. 그러나 클라이언트 측 유효성 검사는 잘못된 요청을 조기에 거부 할 수있는 경우 작업량을 줄이는 좋은 방법입니다.

Answer 3

내가 궁금해하는 것은 내 CLI를 엄청나게 얇게 만드는 데 문제가 있을지 여부입니다.

...

제 경우에는 이것이 개발을 단순화하고 유지 보수 작업을 줄일 것이라고 생각합니다.

사람들은 서버에서 실행되는 CLI를 원격으로 Telnet/SSH를 사용하여 수년간이 작업을 해왔습니다. 어쨌든 모든 지능이 서버에 있어야한다면 CLI를 지능을 가진 분산 클라이언트로 만들 이유가 없을 수 있습니다. 터미널 세션이 되십시오 - SSH를 사용하여 도망 갈 수 있다면, 그것이 내가하는 일입니다. 그러면 클라이언트 작품은 한 번 (또는 아마도 상용 비트의 소프트웨어 만)와 모든 유지 보수 및 모든 유지 보수 및 업그레이드는 서버에서 발생합니다 (1978 년에 오신 것을 환영합니다).

물론 이것은 클라이언트가 지능적이어야 할 필요가없는 경우에만 실제로 적용됩니다 (상황에서 경우와 같은 소리).

Answer 4

요청 문자열에서 이름 / 값 쌍을 사용하는 것은 실제로 널리 퍼져 있습니다. 그러나 그 시점에서 왜 비누가 전혀 귀찮게됩니까? 대신 편안한 아키텍처로 이동합니까?