我正在开始一个新的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
答案 0 :(得分：4)
你应该尽可能绝对使用Javascript SDK。您将获得更好的性能，您的应用程序将更具可扩展性。但是，性能并不总是唯一的考虑因素。有些事情在服务器上更容易。此外，许多应用程序离线（或延迟处理）不涉及直接交互的用户数据。
我不认为使用每个SDK都有正确或错误的地方，但他们肯定都在一个精心构建的Facebook应用程序中占有一席之地。我的建议只是使用每个任务更容易的任何一个。当你的应用程序的增长，你要学习瓶颈在哪里，并在那里你需要真正挤压是通过移动的东西给客户端（使用Javascript SDK）或移动的东西在后台进行处理（Facebook的C＃所需要的性能，额外位SDK）。
通常，我们将Javascript SDK用于某些身份验证内容以及大多数具有用户界面的内容。 UI内容的一个例外是当我们真正关心处理错误时。处理服务器上的错误比使用Javascript SDK容易得多。我所谈论的错误是来自facebook的错误或只是一般的facebook停机时间。
就像我说的那样，在开始时只需使用两者并为每项任务做更轻松的事情。