一部のロジックをサービスとしてローカルに公開する必要があります…</p>
ロジックとの間で送受信されるオブジェクトは非常に大きく、情報は機密性が高く、ローカルサーバーでのみ使用するためにロジックを外部に公開する必要はありません。
一部のMVC開発者は、WEB Apiサービスを使用して公開する必要があると主張しています。これを実装する価値はありますか？
彼らの主張は、Web APIを使用するとMVCにはるかに統合され、結果の表示がはるかに簡単になるというものです（私はこの側面については何も知りません）。複雑な承認を実装してパフォーマンスを犠牲にする必要があるのではないかと心配しています。
このシナリオに適合するより優れた軽量サービスレイヤーはありませんか？WCFの名前付きパイプは、私には論理的であるか、クラスライブラリとして参照しているように見えます。そうです、構成ファイルは面倒ですが、世界の終わりではありません。基本的には、ローカルでロジックを提供したいだけです。
Web APIは、これまでのところMicrosoftの最高の高レベルHTTP実装です。そのため、これまでにないHTTPを採用し、通常のMVCでは不可能な多くの柔軟性を実現します。
コンテントネゴシエーションなどの機能は、内部または外部を問わず、あらゆるサービスにとって本当に重要です。
それでも、WCFは純粋なRPCフレームワークであるため、より優れた結束性を提供することもわかります。しかし、それは間違いなく軽量ではありません。私はここにこの問題について議論し、いくつかの比較を行うブログを持っています（恥知らずなプラグ！）。
プライベート環境でメソッドを呼び出すだけであれば、WCFで問題ありません。ただし、名前付きパイプ/ TCPは、ファイアウォールの状態によっては機能しない場合があることに注意してください。
Web APIで失うもう1つのことは、コントラクトです。Web APIランドにはWSDLはありません。これは、見方によって良い場合と悪い場合があります。会社がサービス契約に非常に厳しい場合は、WCFの方が適しています。
Aliostadにはいくつかの本当に良い点があります。個人的な経験以外に追加することはあまりありません。私は最近、WCFでいくつかの深刻な構成の問題が発生した後、mvcを使用してWebサービスを起動しましたが、それは途方もなく簡単でした。あなたの質問は、軽量でシンプルな実装を求めています-答えは、これらの点で間違いなくWCFよりもMVCWebAPIです。
サービスレイヤーがREST指向の場合は、servicestackを確認できます。
これは実装が非常に簡単で、パフォーマンスを犠牲にすることはなく、属性（ASP.NET mvcのアクションフィルターなど）または継承を使用して、セキュリティを簡単に実装できます。
MVCまたはWebAPIが適切な選択です。より軽量なものが必要な場合は、私が取り組んでいるオープンソースプロジェクトであるhttp://www.nuget.org/packages/DuoVia.Netをご覧ください。