将Web服务请求转换为内部表示？
我正在实现一个接收不同请求的 SOAP-Webservice。我的 Manager 类是否应该在将请求对象委托给实现类之前将其转换为内部表示？
我认为这对于解耦来说是一个好主意。但这样做时，我必须创建每个 RequestObject 类的副本并将其命名为 InternalRequestObject，它存储与原始 Request 相同的数据。
这有道理吗？
I am implementing a SOAP-Webservice which receives different Requests. Should my Manager-class transform this Request objects into an internal representation before delegating them to implementation classes?
I think this would be a good idea concerning decoupling. But doing this I have to create a copy of each RequestObject class and name it InternalRequestObject which stores the same data as the original Request.
Does this make sense?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您打算重用这些实现类，我将其称为您的业务层，这是有意义的。
在您当前的设置中，您将业务层公开为 Web 服务。如果您愿意的话，Web 服务的骨架是业务层的客户端。
现在出现的问题是：您的业务层是否应该关心它将拥有什么样的客户？业务层的数据契约应该由客户端决定，还是客户端应该尊重业务层公开的数据契约？
明显的反应是客户端应该尊重业务层的数据契约，因此您的问题的答案是：是，您应该将 SOAP 请求映射到实现类使用的内部请求类型以获得两者之间更好的解耦。
只有一种情况我会考虑直接使用请求类型一直深入到我的业务层：如果我绝对（101%）确定我永远不必将我的业务层公开为 SOAP 之外的任何其他层网络服务。
这个想法是，你此时只有两个主要选择：
1。在所有地方保持相同的请求类型。这样做的缺点是，如果在某些时候您必须添加其他（非 SOAP）客户端，您将遭受大量重写，破坏您的业务层。
或
2。将 SOAP 请求类型映射到内部类型。这样做的缺点是，您可能会冒着重复代码和额外工作的风险，但最后却发现一切都是徒劳，而且您根本不需要添加其他客户端。
考虑一下自己的情况，慎重选择！但我必须告诉你，就我个人而言，到目前为止我还没有遇到过第二个缺点。我总是最终向该事物添加新客户端，此时它有助于从一开始就映射类型。
It makes sense if you intend to reuse those implementation classes which I would call your business layer.
In your current setup, you have the business layer exposed as a web service. The skeleton of the web service is - if you will - a client for your business layer.
Now the question that arises is: should your business layer care what kind of clients it will have? Should the data contract of the business layer be dictated by the clients, or should the clients respect the data contract exposed by the business layer?
The obvious response is the clients should respect the data contract of the business layer, so the answer to your question would be: Yes, you should map the SOAP requests to an internal request type used by the implementation classes in order to obtain a better decoupling between the two.
There is only one case in which I would consider using the request types directly all the way down into my business layer: If I would be absolutely (101%) sure that I will never have to expose my business layer as anything else than a SOAP web service.
The idea is that you only have two main options at this:
1. keep the same request type all over the place. The disadvantage to this is that you will suffer a lot of rewrites ripping through your business layer if at some point you have to add other (non SOAP) clients.
OR
2. map the SOAP request type to an internal type. The disadvantage to this will be that you risk duplicating code and working extra just to find out at the end that all was for nothing and you didn't need to add other clients after all.
Think about your situation and choose carefully! But I must tell you that, personally, I haven't encountered the disadvantage of number 2 so far. I always ended up adding new clients to the thing and at that point it helped having mapped the types from the very beginning.