移动CLI验证/逻辑服务器端有什么问题吗?

时间:2009-01-09 20:01:09

标签: client-server command-line-interface

我有一个客户端/服务器应用程序。其中一个客户端是CLI。 CLI执行一些基本验证,然后向服务器发出SOAP请求。解释响应并向用户呈现相关信息。每个命令都涉及对Web服务的请求。

每次在服务器端修改服务时,都需要发布新的CLI。

我想知道的是,如果让我的CLI非常薄,那会有什么问题。它所做的就是将命令字符串发送到服务器,在那里验证,解释并返回响应字符串。

(甚至可以通过服务器的合作完成TAB完成。)

在我看来,这会简化开发并减少维护工作。

我有没有陷入困境?

更新

可伸缩性问题不是重中之重。

4 个答案:

答案 0 :(得分:1)

一般情况下,您可以,但如果可以提前拒绝错误的请求,客户端验证是减少工作量的好方法。

答案 1 :(得分:1)

我认为这只是一个品味问题。验证必须在某处进行;您只是在软件中以相同的复杂性来处理客户端的复杂性。这对你的架构来说不一定是坏事;您实际上只是提供一项附加服务,为呼叫者提供访问现有服务的替代方法。我要注意的唯一缺陷是代码重复;如果您发现CLI验证与某些服务(例如,解析数字)执行的操作相同,则重构以避免重复。

答案 2 :(得分:1)

  

我想知道的是,如果让我的CLI非常薄,会有什么不妥。

     

...

     

在我看来,这会简化开发并减少维护工作。

人们多年来一直使用telnet / SSH远程操作服务器上运行的CLI。如果所有智能都必须在服务器上,那么可能没有理由让您的CLI成为具有智能的分布式客户端。只是让它成为一个终端会议 - 如果你可以使用SSH,这就是我要做的 - 然后客户端部分完成一次(或者可能只是一个现成的软件)和所有的维护和升级发生在服务器上(欢迎来到1978年)。

当然,如果真的没有要求客户端智能化(这听起来就像你的情况那样),这才真正适用。

答案 3 :(得分:0)

在请求字符串中使用名称/值对实际上非常普遍。但是,在那一点上,为什么要烦恼SOAP呢?而只是转向RESTful架构?