クライアントとしてWPF、サーバーとしてWCFの代わりにSilverlightを使用することを考えています。それは理にかなっていますか？
私はこれらの利点があると思います：
1) Web であるため移植性が高い。
2) クライアント アプリケーションとサーバー アプリケーションの両方でユーザー入力を検証する必要はありません。
3 番目の利点は私の主な質問です。ユーザーは私のコードを見ることができないので、私のアプリケーションはハッカーに対して安全であると思います。これは正しいです？これは、Silverlight にデータベース接続文字列を保存すると、どのクライアントからもそれが表示されないということですよね?
ありがとう。
Silverlight アプリケーションがパッケージ化されている .xap ファイルは、アプリケーションの DLL を含む単なるアーカイブであるため (名前を .zip に変更して確認してください)、.xap をダウンロードした人がコードを逆コンパイルできます。
2番目のポイントについては、サーバーで検証する必要があります。たとえば、トラフィックをスニッフィングして、アプリケーションが WCF Web サービスを呼び出していることを確認できます。そこから、アプリケーションを使用せずに、サービスに独自のリクエストを作成できます。サーバー側を検証しないと、悪いことが起こります。
また、Silverlight の「移植性」については議論の余地がありますが、.exe よりも移植性が高いと思います。
1) Web であるため移植性が高い。
ここで「ウェブ」の意味を定義する必要があります。iOS（Safariを使用）、Androidデバイス、またはおそらく他のデバイスでは（私が何かを見逃していない限り）動作しません。たとえば、純粋な HTML5 アプリケーションが「Web」であるのと同じように、「Web」ではありません。
2) クライアント アプリケーションとサーバー アプリケーションの両方でユーザー入力を検証する必要はありません。
これは、入力が実際にクライアントからのものであることをサーバーが「認識」できる場合にのみ当てはまります。単なる Web リクエストの場合は、何からでも投稿できます。私の経験では、常にサーバーで検証する必要があります。クライアント側の検証は、ユーザーの生活を楽にするためにあります。サーバー側の検証は、実際にビジネス ルールを適用することです。
3 番目の利点は私の主な質問です。ユーザーは私のコードを見ることができないので、私のアプリケーションはハッカーに対して安全であると思います。これは正しいです？
いいえ。コードはユーザーのマシンで実行されています。ダウンロードされ、他の .NET アセンブリと同様に逆コンパイルできます。
アセンブリは簡単に抽出して逆コンパイルできます。また、アプリケーションがクライアントで実行されている場合、要求がアプリケーションからのものであることを知ることはできないため、サーバーの検証をスキップすることさえ考えないでください。