MVC から Prism で WPF を実行するようになったときに、Prism の本を購入しましたが、アンチパターンとして知られている Service Locator がまだ表示されていることにもう一度ショックを受けました。私は .NET での Dependency Injection などの本を読んだことがあり、Mark Seemann は WHY Service Locator がアンチパターンである理由を徹底的に説明しています。
私は単にベスト パターンとプラクティスのエバンジェリストになろうとしているだけであり、これらのパターンのいくつかが実際には悪いというメモを受け取っていない人を知りたいと思っています。
科学と芸術の間には確かにバランスがあります。パターンは意図的に発明されたものではなく発見されています。一部の言語は、より多くのソフトウェアエンジニアリングの原則に従うのに適しています。これについては確かに議論の余地がたくさんあります。あなたは何かの使い方を疑うのは正しいと思いますが、あなたが言及した他の質問が「非常に」有名な人々が互いに意見を異にしているように見えるので、あなたがあなたの答えを見つけるかどうかはわかりません。
必要な問題とそれが使用される状況について、さらに明確にする必要があります。全体として、これらの「アンチパターン」の使用を分析する必要があると思います。私が読んだシングルトンは悪いですが、私たちは皆、それが目的を持っていることを知っています。
最初に事実を明確にする: Prism は ServiceLocator の使用を推奨していません。これは質問を無意味にします。たぶん、質問の名前を「プリズムの本が奨励するのはなぜですか...」に変更したいと思うかもしれません。
Prism は、Microsoft の IoC コンテナーの実装である Unity IoC 上に構築されています。タイプを登録すると、適切にビルドされます。これを行う方法を示すインターネット上の多くの記事があります。
さて、石鹸箱の部分：
I would argue that there are no such things as best practices, as any 'best practice' don't make sense in certain context. For example, when I see a singleton, it always rings an alarm, but there are situations where it is OK to have it. Even 'goto' is sometimes justified (oh my God! what did he just say?!?!)
Now, I don't know much about Prism, but IMO, service locator can make perfect sense, especially if it is used inside a framework, as it can leave the developer with more design and implementation choices, and that should be the developer's call.
To really understand whether it is a wrong decision (and it likely might be) it would be interesting to see what things developers using Prism can't do because of alleged use of ServiceLocator, which otherwise would be possible if Prism used DI.