我正在开始一个新的Facebook画布应用程序，所以我可以选择我将要使用的技术 . 我一直是.NET平台的粉丝，所以我非常考虑这个应用程序 . 我认为完成的工作是：facebooksdk.codeplex.com
看起来很有希望 . 但我的问题如下：
我的理解是，在使用Facebook这样的应用程序框架（或PHP）时，每当我们调用API来执行某些操作（比如发布到流中）时，流程将如下所示：
-User启动请求，该请求被定向到ASP.NET服务器
-ASP.NET服务器进行Facebook API调用
所以总共涉及三台机器 .
为什么不使用Javascript SDK呢？
http://developers.facebook.com/docs/reference/javascript/FB.api
“通过JavaScript SDK可以获得服务器端调用，允许您构建丰富的应用程序，可以直接从用户的浏览器对Facebook服务器进行API调用 . 与在服务器上进行所有调用相比，这可以提高许多情况下的性能 . 它还可以帮助减少或消除通过您自己的服务器代理请求的需要，从而使他们能够做其他事情 . “
因此，在我看来，我将把我的ASP.NET服务器排除在外，将涉及的机器数量从三个减少到两个 . 我的服务器负载较小，用户（可能）性能更高 .
我是否正确使用Facebook C＃SDK，我们有三个机器方案而不是JS API的两个机器方案？
现在我明白像ASP.NET这样的Web服务器框架提供了很好的好处，比如很棒的开发工具，回发基础设施等等，但是我在这里有一个不完整的图片吗？使用C＃框架是否有意义，但仍然依赖于大多数FB api调用的javascript sdk？应该何时使用？
最好，
-ben
1 回答
你应该尽可能绝对使用Javascript SDK . 您将获得更好的性能，您的应用程序将更具可扩展性 . 但是，性能并不总是唯一的考虑因素 . 有些事情在服务器上更容易 . 此外，许多应用程序离线（或延迟处理）不涉及直接交互的用户数据 .
我不认为使用每个SDK都有正确或错误的地方，但他们肯定都在一个精心构建的Facebook应用程序中占有一席之地 . 我的建议只是使用每个任务更容易的任何一个 . 随着您的应用程序的增长，您将了解瓶颈的位置以及您需要真正挤压的位置，无论是将内容移动到客户端（Javascript SDK）还是移动要在后台处理的内容（Facebook C＃） SDK） .
通常，我们使用Javascript SDK进行一些身份验证，以及使用用户界面的大部分内容 . UI内容的一个例外是当我们真正关心处理错误时 . 处理服务器上的错误比使用Javascript SDK容易得多 . 我正在谈论的错误是来自facebook的错误或只是一般的facebook停机时间 .
就像我说的那样，在开始时只需使用两者并为每项任务做更轻松的事情 .