我正在考虑使用Silverlight而不是WPF作为客户端和WCF作为服务器。它是否有意义？
我想我会有这些优势：
1）因为它是Web，所以更加便携。
2）我不需要在客户端和服务器应用程序中验证用户输入。
第三个优点是我的主要问题：我猜用户无法看到我的代码，因此我的应用程序可以安全抵御黑客攻击。它是否正确？这意味着如果我在Silverlight中存储数据库连接字符串，没有客户端会看到它，对吧？
感谢。
答案 0 :(得分：3)
打包Silverlight应用程序的.xap文件只是一个包含应用程序DLL的存档（将其重命名为.zip并自行查看），因此下载.xap的任何人都可以反编译您的代码
至于你的第二点，你应该在服务器上验证。例如，我可以嗅探流量并看到您的应用程序调用WCF Web服务。从那里我可以在不使用您的应用程序的情况下自行提出您的服务请求。如果你不验证服务器端的坏事就会发生。
此外，Silverlight的“可移植性”是有争议的，但是我猜它比.exe更便携。
答案 1 :(得分：2)
1）因为它是Web，因此更具便携性。
更便携：是的，但仅限于SL范围。
2）我不需要在客户端和服务器应用程序中验证用户输入。
验证：始终在服务器上重复客户端验证。无论您在客户端使用什么，都不要相信它。
我猜用户无法看到我的代码，因此我的应用程序可以安全抵御黑客攻击。它是否正确？
不，非常不是这样。黑客仍然可以检查和反汇编您的代码。
这意味着如果我在Silverlight中存储数据库连接字符串，没有客户端会看到它，对吧？
不，按上述方式。但SilverLight无论如何都没有太多用于数据库连接字符串...
SL没有ADO.NET库。也许“SL Full Trust”可以使用它们但我对此表示怀疑。
答案 2 :(得分：2)
1）因为它是Web，所以更加便携。
你必须在这里定义“web”的含义。它在iOS（使用Safari）或Android设备或其他一些设备上都不起作用（除非我遗漏了一些东西）。它不是“web”，就像纯HTML5应用程序是“web”一样。
2）我不需要在客户端和服务器应用程序中验证用户输入。
只有服务器能够“知道”输入真正来自客户端时才会出现这种情况。如果它只是一个Web请求，它可以通过任何方式发布。根据我的经验，您应该始终在服务器上进行验证 - 客户端验证可以使用户的生活更轻松;服务器端验证是为了真正实施业务规则。
第三个优点是我的主要问题：我猜用户无法看到我的代码，因此我的应用程序可以安全抵御黑客攻击。这是对的吗？
没有。代码在用户的机器上运行;它将被下载，并且可以像任何其他.NET程序集一样进行反编译。
答案 3 :(得分：1)
组件可以轻松提取和反编译，如果请求来自您的应用程序，如果它在客户端上运行，那么您甚至不会认为关于跳过服务器验证。