2

不久前，我开始了一份新工作，他们一直在使用 WCF 处理 UI 和后端之间的所有数据/业务逻辑，这很棒。

我注意到，这些 WCF 服务调用中的绝大多数都包含各种参数。例如，假设您有一个名为 GetFoo 的服务调用。在这里，我们可能会使用如下签名：

public Foo GetFoo(int? ID, string Name, DateTime? fooDate)

对于更面向对象的方法，您可以改为使用：

public Foo GetFoo(Foo foo)

在这种情况下，代码从 POCO 对象中获取它需要的内容，Foo而不是依赖于从 UI 传入的一组特定参数。

一方面，这在 UI 和 WCF 服务之间提供了更灵活的契约。我们可以在不违反任何合同和更新引用的情况下对服务端的实现进行更改。此外，我们可以让业务对象直接作用于 POCO，而不是处理显式的参数列表。

另一方面，尚不清楚需要什么才能获取您想要的对象/数据。

哪种方法被认为是最佳实践？

4

4 回答 4

1

我总是选择单参数输入和输出。该参数定义了我期望的数据的消息（或至少是消息体），并且返回定义了我要发回的消息体

如果您使用多个参数，您几乎无法控制在线上的消息外观。

合同操作是 .NET 方法这一事实是一个实现细节。契约的目标是定义消费者和服务之间的消息结构。

于 2012-05-15T10:40:17.943 回答
1

我建议第三种更详细的方法：

public Foo GetFooByName(string Name)
public Foo GetFooByIDAndName(int ID, string Name)
public Foo GetFooByNameAndDate(string Name, DateTime fooDate)
public Foo GetFooByIDNameAndDat(int ID, string Name, DateTime fooDate)

等等等等。为了 DRY，您可能会提取公共代码并制作一些private方法。这导致了自我描述的代码，并且可以更准确地查明错误（更不用说您可以更改单个方法而其他方法不受影响，这总是好的）。

于 2012-05-15T10:44:26.213 回答
0

OOP 是我们大多数人所追求的。如果你意识到，你需要在 Foo 对象上添加一个新属性，而 Foo 对象有 15-20 个方法，这些方法有子方法等等，这只是臭代码，它会节省你做正确事情的时间（哎呀imo :)）。

多少参数太多了？更多信息

我建议你看看 Martin Fowlers 关于重构的书，他说了大多数程序员的想法，但出于某种原因我们不这样做。

于 2012-05-15T10:31:24.367 回答
0

您可以同时拥有两者，但应该清楚它们的含义。您现在拥有的两种方法都不清楚它们的作用。第一个：

如果我通过了会发生什么：

ID = 1
Name = "Name"
fooDate = NULL

然后我要求 id = 1 和 name = "Name" 的项目，或者我要求 id = 1 和 name = "Name" 和 fooDate = null 还是要求 id = 1 或 name = "Name" ro fooDate =无效的。

在这种情况下，至少 Id 应该是一个单独的函数。

在您的第二个示例中，您创建了一个函数，我称之为 get by example。但是，您不能要求特定的 NULL 值。除此之外，我不会将其称为面向对象的方法，因为您传入了一个对象。OO 更多的是关于对象如何相互交互。

在选择一个方法时，要更明确地说明你的功能是做什么的。如果您确实需要一个可以传入对象并构建动态查询的函数。调用函数 GetFooByFooExample。但是，如果您只填写 id，请考虑使用 GetFooById 之类的函数，这会使您的代码更具可读性和自我解释性。

于 2012-05-15T10:28:05.413 回答