基本问题:ExchangeService与ExchangeSerivceBinding? [英] Basic Question: ExchangeService versus ExchangeSerivceBinding?

查看:136
本文介绍了基本问题:ExchangeService与ExchangeSerivceBinding?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

您好。  所以我可以直接使用API​​,ExchangeServices和Exchange服务绑定到Exchange 服务器。  我的问题很简单......有什么区别?  例如,我使用的帐户可以访问所有邮箱,并且需要为用户创建约会。  现在,我可以模仿使用Binding,抑制Invite,一切都很好。  但是那不是使用API​​ ...但是我没有在引用API时丢失了什么?

Hi.  So I'm able to use both, ExchangeServices using the API and ExchangeServicesBinding to the Exchange Server directly.  My question is real simple...what is the difference?  For example, I use an account that has access to all mailboxes, and need to create appointments for users.  Now, I can impersonate using the Binding, suppress the Invite, and all is well.  But that's not using the API...but what did I lose in not referencing the API?

这是我正在尝试为以下内容创建证据的另一个用例:对于用户,请查看该用户是否在某一天的特定时段内有任何约会。  我假设我不需要冒充这个,但我无法在任何地方找到很多信息来分解Web引用和API引用之间的区别。  到底他们迥然不同?  我查看了大量示例,因为API是最新的,所以大多使用ExchangeServicesBinding对象。  但是我遇到过几种似乎只能用于其中一种方法的方法......但看起来彼此非常相似。

Here's another use case that I'm trying to create a proof for: For a user, see if that user has any appointment during a certain span on a certain day.  I assume I don't need impersonation for this one, but I just can't find much info anywhere that breaks down the difference between web reference and the API reference.  In the end are they very different?  I've looked at a slew of samples and since the API is new most use the ExchangeServicesBinding object.  But I've come across a couple methods that seem to only be available to one or the other...but seem very similar to each other.

我想我错过了大局,但为什么我应该使用API​​代替绑定 直接进入网络参考?  

I think I'm missing the big picture, but why SHOULD I use the API instead of binding right to the web reference?  

这可能更像是一个最佳实践帖,但由于两者之间的相似性以及两者之间的差异,我不得不停留在下一步的位置。

This might be more of a best practices post, but I'm half stuck on where to go next because of the similarities...and the differences between the two.

谢谢。

- 布莱恩

推荐答案

布莱恩,

您可以使用自动生成的代理或API执行几乎所有操作。 API基本上是自动生成的代理的替代品,但它们都在谈论EWS协议,并且具有相同的功能。

You can do pretty much everything with either auto-generated proxies or the API. The API is basically a replacement for the auto-generated proxies, but they both talk the EWS protocol under the covers and are capable of the same things.

如果您正在进行.NET开发,我们强烈建议您使用API​​。原因很简单(可能是您所指的"大图"):

If you are doing .NET development, we strongly recommend you use the API. The reasons are simple (that might be the "big picture" you are referring to):


  • 您将比自动生成更快地学习API代理

  • 您可以编写更少的代码来获得完全相同的结果

  • 您的代码将更易于维护并且错误更少

  • 托管API内置一些智能逻辑,否则您必须手动实现

  • 托管API具有内置的自动发现实现

  • 迁移到新版本的Exchange时,您必须重新生成代理才能利用新的EWS功能。无法保证您当时使用的代理生成器将生成与您的应用程序兼容的类。使用API​​更安全

  • You'll learn the API much faster than auto-generated proxies
  • You'll write much less code to get to the exact same result
  • Your code will be way more maintainable and will have less bugs
  • The managed API has some smart logic built-in that you would otherwise have to implement manually
  • The managed API has a built-in Autodiscover implementation
  • When moving to a new version of Exchange, you will have to regenerate your proxies to take advantage of new EWS features. There is no guarantee that the proxy generator you are using at that time will generate classes that are compatible with your application. You are safer with the API

我们创建了API来解决开发人员使用自动生成的代理所带来的痛苦经历。我认为你应该使用API​​,你会很开心。

We created the API to address the painful experience developers were having with auto-generated proxies. I think you should use the API, you'll be happy you did.


这篇关于基本问题:ExchangeService与ExchangeSerivceBinding?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆