我有一个服务方法,其中包含一些将始终提供的参数以及将根据名称和参数数量更改的其他参数(我将知道ACTION字段需要哪些参数)
为解决上述设计问题,我创建了一个Web服务,其中包含将始终提供的参数以及另一个接受以Key< *>值方式编写的字符串的参数。
使用MyServiceMethod:
Action : Action1
Param2: Hello
param3: world
Additional_Params: name<*>Jack;address<*>2 street;
(我知道使用Action1我会从使用该服务的人那里获得名称和地址值)
第二次使用MyServiceMethod:
Action : Action5
Param2: Hello
param3: world
Additional_Params: numOfHours<*>3;Sum<*>342;myName<*>asaf;
我认为这不是每个ACTION接受不同数据的Web服务的最佳设计,有更好的方法吗?
答案 0 :(得分:2)
如果您有一小组操作,那么对每个操作简单地使用单个方法可能是最好的设计策略。在后端可能不需要那么多的工作来分开,在我看来,它并没有羞耻。
如果您有大量操作,则可以表示您想要作为数据结构执行的操作,并仅传递该参数。
我不会说你提出这样做的方式是错的,但是它实际上最终会为你创造更多的工作,并在以后让你或其他开发人员感到困惑。
答案 1 :(得分:2)
我不是100%清楚你要做什么,但如果你知道Action1
将始终使用“name”和“address”的名称/值对进行调用,并且{将使用“numOfHours”,“Sum”和“myName”调用{1}},然后我同意@Eugarps答案和@Steven_Sudit相关评论。只需将它们作为参数展示在每个操作的方法上。
但是,如果你不知道变量参数是什么(只是你在调用动作时会获得某些名称/值对),那么我至少会使用Action5
而不是一个字符串。这样做意味着您可以避免解析字符串值。如果传递的值是您自己类型的实例(而不是基元),那么您还需要使用IDictionary<string, object>
属性来告诉序列化器它们。
答案 2 :(得分:0)
我已经在评论中得到了回答,但这里有一个地方:
如果您有少量不同的功能,这些功能很少变化,最好的方法就是将每个功能作为单独的功能公开。当需要新的时,您可以在不破坏现有代码的情况下扩展您的界面。
现在,另一方面,如果你有更多的功能和/或他们经常更改,那么一个简单但灵活的界面会更好。您可以公开一个函数,获取XML文档,该文档是请求DTO的序列化。这将需要一些解复用逻辑(switch / case或更好的代理查找表)来将请求分派给处理程序。这种方法难以开始,但更容易维护。