设计WCF服务接口。过程式设计与面向对象设计
我们正在构建可供其他系统使用的产品。由于我们有 SOA，所以我们只开发一个服务（WCF）。关于如何设计该服务的界面，我们进行了几次有争议的讨论。我们在服务的过程设计和面向对象设计之间进行选择。
由于我们的服务将使用.NET和Java，因此有人说如果它是面向对象的设计，那么很难与服务集成。其他人认为服务不能使用面向对象的方法。有人说OO完全可以。结果我们没有明显的抑郁症。
WCF 提供了使用这两种设计的简单方法，但什么是最好的呢？
we are building product that can be used by other systems. As we have SOA, we develop only a service (WCF). We had several controversial discussions about how to design an interface of that service. We are choosing between procedural and OO design for service.
As our service will be used from .NET and Java some say that it is hard to integrate with service if it has OO design. Other think that services mast not use OO approach. Some say that OO is completely OK. As result we there is no clear depression on it.
WCF provide easy way to use both designs but what is the best?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我假设您使用的“面向对象”的定义是管理“对象”的程序的概念，并且这些单独的对象管理其内部状态并公开要调用的函数。
与此最接近的 WCF 是基于会话的服务，其中每个服务实例的生命周期由客户端控制。
如果您希望通过 Java 调用此服务，则必须使用 basicHttpBinding，因为它使用经典的 Web 服务协议。
此绑定不提供对基于会话的服务的支持，因此您实际上无法使用基于会话的服务。
因此，您不能将“面向对象”范式应用于服务本身。
I assume the definition of "Object Oriented" you are using is the concept of the program managing "Objects", and these individual objects manage their internal state and expose functions to be called.
The closest WCF parralel to this is Session-based services, where the lifetime of each service instance is controlled by the client.
If you want this service to be invoked by Java you would have to use basicHttpBinding, as this uses the classic web-service protocol.
This binding does not provide support for session-based services, so you literally cannot use session based services.
Therefore, you cannot apply the "object-oriented" paradigm with regard to the service itself.
您通过说以下内容来澄清您原来的问题：
“我的问题是关于服务的方法是否应该接收复杂类型而不是标量参数？”
您应该问自己以下问题：
a) 该服务是否有可能被非 OO 客户端使用？不知道，COBOL 批次？即使您的公司已经标准化了 OO 技术 (Java/.NET)，该特定服务将来是否有可能被某些外部实体（客户、PHP 网站等）使用
b) 您是否已经创建了许多这样的服务？过去的服务（因此您完全确定复杂类型不存在编组/序列化/反序列化问题，或者至少知道您可以安全地使用什么）？
如果您对这两点完全有信心，那么请随意使用“OO”方法来设计您的服务的输入和输出。否则，请采用最安全（如果更原始）的方法，并将“对象”分解为标量组。
You clarify your original question by saying:
"My question is about the methods of the service should they receive complex types instead of scalar parameters?"
You should ask yourself the following:
a) Is there any chance that the service may be used by non-OO clients? Dunno, a COBOL batch? Even if your company has standardized on OO tech (Java/.NET) is there any chance that this specific service may be used in the future by some external entity (customer, PHP website, whatever)
b) Have you already created many such a service in the past (so you are perfectly sure there is no marshalling/serializing/deserializing problems with complex types, or are at least aware what you can safely use)?
If you are fully confident about both points, then feel free to use an "OO" approach in designing both inputs and outputs for your service. Otherwise, go for the safest (if more primitive) approach, and decompose the "objects" in groups of scalars.