我们正在构建可供其他系统使用的产品。因为我们有SOA，所以我们只开发一个服务（WCF）。关于如何设计该服务的界面，我们曾经进行过多次有争议的讨论。我们正在选择程序和面向服务的OO设计。设计WCF服务接口。程序与面向对象的设计
由于我们的服务将从.NET和Java中使用，有人说如果它具有OO设计就很难与服务集成。其他人认为服务不使用面向对象方法。有人说OO是完全正确的。结果我们没有明显的抑郁症。
WCF提供了使用两种设计的简单方法，但最好的是什么？
我假设您使用的“面向对象”的定义是管理“对象”的程序的概念，并且这些单独的对象管理它们的内部状态并公开要调用的函数。
对此最接近的WCF parralel是基于会话的服务，其中每个服务实例的生存期由客户端控制。
如果您希望Java调用此服务，则必须使用basicHttpBinding，因为它使用经典的Web服务协议。
此绑定不提供对基于会话的服务的支持，因此您实际上不能使用基于会话的服务。
因此，您无法将“面向对象”的范例应用于服务本身。
+1，而且采用OO方法进行服务设计会导致服务过于细化。你应该瞄准服务是粗粒度的。我想用'消息'而不是'对象'来思考。 – 2010-10-13 14:06:24
您通过说： “澄清你的原始问题”如果他们接收复杂类型而不是标量参数，我的问题是关于服务的方法？
你应该问自己以下：
一）是否有该服务可以通过非面向对象的客户端使用的任何机会呢？不知道，COBOL批次？即使贵公司已经在面向对象技术（Java/.NET）上进行了标准化，未来某种外部实体（客户，PHP网站，不管）是否有可能使用此特定服务
b）您是否已经在过去创建了许多这样的服务（所以你完全确定复杂类型没有编组/序列化/反序列化问题，或者至少知道你可以安全使用什么）？
如果您对这两点都充满信心，那么可以在为您的服务设计输入和输出时使用“OO”方法。否则，请选择最安全（如果更原始）的方法，并分解标量组中的“对象”。
我看不出服务接口是如何真的，它只是一个Web服务接口。你问是否服务的方法应该返回/接收复杂类型而不是标量参数？如果这就是你要求的，使用复杂的类型。或者你问网络服务的实现是否应该遵循面向对象的设计？ – JeremyWeir 2010-10-13 06:00:55
感谢您的回答。我的问题是关于服务的方法，如果他们接收复杂类型而不是标量参数？只是“使用复杂类型”不是一个争论。 – 2010-10-13 07:05:03