在 API 中从延迟/延迟加载转换为急切加载的首选方法?

发布于 2024-08-15 10:30:31 字数 339 浏览 12 评论 0原文

我已经研究一个 API(它包装了某种 Web 服务)有一段时间了,它的功能已经很完整了。

我最初将该 API 设计为自始至终都是惰性/延迟加载的;考虑到使用 Web 服务固有的延迟,如果您只对可用数据的一小部分感兴趣,那么这是非常有意义的。然而,我没有考虑到一些用例,在这些用例中,急切加载对于 API 的使用者来说会更容易。

所以,我的问题是:您希望看到一个主要是延迟加载的 API 公开一种获取类的急切加载版本的机制吗?

我倾向于显式强制转换,但是Eager.AsEager(SomeDelayLoadingObject)的一些内容如果更冗长的话似乎也很自然。

I've been working on an API (which wraps a web-service of sorts) for a while now, and its just about feature complete.

I initially designed this API to be lazy/delay-loaded throughout; which makes perfect sense if you're only interested in a small subset of the available data given the latency inherent in consuming a web-service. However, I failed to consider a few use cases where eager loading would be much easier on a consumer of the API.

So, my question is: How would you like to see an API that is predominately lazy-loading expose a mechanism for getting eagerly-loaded versions of classes?

I'm leaning towards an explicit cast, but something along the lines of Eager.AsEager(SomeDelayLoadingObject) also seems natural if more verbose.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

愚人国度 2024-08-22 10:30:31

我实际上最终做的是创建我想要急切加载的类的浅表副本,这些类没有功能代码但具有所有相同的属性。

然后,我定义了两个隐式转换:lazy->eager 和 eager->lazy。两次转换都复制了所有属性;从而在需要时触发任何加载。

虽然我不认为这是一个完美的解决方案,但它使得急切地加载简单的更改类型;无需更改代码。

What I actually ended up doing was creating a shallow copy of the classes I wanted to be eagerly loaded, classes with no functional code but with all the same properties.

I then defined two implicit casts, from lazy->eager and eager->lazy. Both casts copied all properties; thereby triggering any loading if it was needed.

While I don't think this is a perfect solution, it makes eagerly loading simply changing types; no code changes are needed.

后eg是否自 2024-08-22 10:30:31

您的 API 正在包装 Web 服务,因此您的 API 或多或少充当代理。我会将加载行为放在代理本身或某种代理上下文上,而不是放在类上。

// Basic: Every operation through the proxy uses Eager loading
using (var proxy = new ApiProxy(Loading.Eager))
{
  var result = proxy.DoSomething();
}

Your API is wrapping a webservice, so your API is more or less acting as a proxy. I would put the loading behavior on the proxy itself, or on some kind of a proxy context, rather than on the classes.

// Basic: Every operation through the proxy uses Eager loading
using (var proxy = new ApiProxy(Loading.Eager))
{
  var result = proxy.DoSomething();
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文