0

我继承了一个 WCF 服务，它充当文件缓存（每个文件代表对第三方 API 的请求的结果）。目前，如果文件不存在，则代码会创建一个新请求来创建数据，并且还会向客户端代码引发异常。

我认为这个想法是客户会回来再次请求文件，然后他们就可以使用它（生成文件需要几秒钟）。

我认为这里有代码味道，我应该重写这部分。目前，异常正在通过几种方法被捕获并冒泡。我认为我应该从源头确定文件是否存在并将该信息传递到调用堆栈。

在 WCF 界面，我目前有一个GetValue()方法，尽管我认为可以使用两个选项来替换它：

  1. null如果文件不存在则返回。
  2. 使用bool TryGetValue(string key, out string value)方法

有没有人有任何偏好/建议？

谢谢

4

1 回答 1

1

“TryGet”方法更明确一点。使用返回 null 的方法，您必须记录该方法出于某种原因返回 null，这需要开发人员阅读文档。众所周知，有些人对阅读文档过敏。

“TryGet”方法的另一个优点是您可以使用枚举而不是布尔值，向调用者提供有关方法失败（或成功）的原因和方式的更多信息。

Jeffrey Richter（C# 中的 CLR）对异常的定义：当动作成员无法完成其任务时，该成员应抛出异常。异常意味着操作成员未能完成其名称所指示的应执行的任务。我的问题是我应该保持 GetValue 方法对客户端可用，并在数据不可用时引发错误，还是将其删除并用 TryGetValue() 替换？

当您确定 API 的设计时，Jeffrey Richter 的定义没有帮助，因为这包括确定每个操作成员的任务应该是什么。

在您的设计中，您理所当然地期望该值不可用；这意味着该值不可用并非例外情况。 因此，我只会使用TryGet ... 模式。

但是，说实话，我会完全采用不同的方法。假设有人尝试这种方法：

while (!TryGetValue(key, out value)) {}

或者：

SomeType value;
bool flag = false;
while (!flag)
{
    try
    {
        value = GetValue(key);
        flag = true;
     }
     catch {}
}

您的 WCF 服务将获得大量点击。研究异步模型可能会更好，因此当结果准备好时通过回调通知客户端，而不是邀请客户端不断轮询服务。

于 2012-05-08T14:33:51.753 回答