我正在考虑使用 Silverlight 而不是 WPF 作为客户端和 WCF 作为服务器。这有意义吗？
我想我会有这些优势：
1) 更便携，因为它是 Web。
2) 我不需要在客户端和服务器应用程序中验证用户输入。
第三个优点是我的主要问题：我猜用户看不到我的代码，所以我的应用程序可以安全地抵御黑客。它是否正确？这意味着如果我在 Silverlight 中存储数据库连接字符串，没有客户端会看到它，对吗？
谢谢。
问问题
147 次
3 回答
3
打包您的 Silverlight 应用程序的 .xap 文件只是一个包含应用程序 DLL 的存档（将其重命名为 .zip 并自行查看），因此下载 .xap 的任何人仍然可以反编译您的代码。
至于您的第二点，您应该在服务器上进行验证。例如，我可以嗅探流量并查看您的应用程序调用了 WCF Web 服务。从那里我可以在不使用您的应用程序的情况下向您的服务提出自己的请求。如果你不验证服务器端的坏事将会发生。
此外，Silverlight 的“可移植性”是有争议的，但我想它比 .exe 更便携。
于 2012-09-30T22:31:43.503 回答
2
1) 更便携，因为它是 Web。
好吧，您必须在这里定义“网络”的含义。它在 iOS（使用 Safari）或 Android 设备或其他一些设备上不起作用（除非我错过了什么）。它不是“web”，就像纯 HTML5 应用程序是“web”一样。
2) 我不需要在客户端和服务器应用程序中验证用户输入。
只有当服务器可以“知道”输入确实来自客户端时，这才是正确的。如果它只是一个网络请求，它可以被任何东西发布。根据我的经验，您应该始终在服务器上进行验证——客户端验证可以让用户的生活更轻松；服务器端验证是真正执行业务规则。
第三个优点是我的主要问题：我猜用户看不到我的代码，所以我的应用程序可以安全地抵御黑客。它是否正确？
不，代码在用户机器上运行；它将已被下载，并且可以像任何其他 .NET 程序集一样进行反编译。
于 2012-09-30T22:32:42.727 回答
1
该程序集可以很容易地被提取和反编译，如果它在客户端上运行，您永远不会知道请求来自您的应用程序，因此甚至不要考虑跳过服务器验证。
于 2012-09-30T22:32:37.140 回答