コーディング規約を設けているところは多いでしょう。開発者のレベルが伴わず、LINQやジェネリックの使用を禁止しているところもあると聞きます。いくらLINQやジェネリックの導入によって開発効率が上がるとしても、それぞれの事情がありますので仕方のないことでしょう。
MVVMをどのように構築するのかも同じであり、それぞれのレベルにあった構築規約を作成すれば良いと思うのです。コーディング規約と同じように、これという正解がないのだと思います。ただし、一般的にベターな実装というのはあると思います。
例えばMVVMでよく耳にするのが、Viewのコードビハインドを書いてはいけない、ViewがViewModelのインスタンスを持ってはいけない、ViewModelがViewのインスタンスを持ってはいけないなどです。これらの意味はわかります。しかし、これらはMVVMに付加された規約であり、必ずしも全ての人がこれに従う必要はないと思うのです。
MVVMで私が最も重視することは疎結合です。疎結合を実現するために多くの場合コマンドが利用されます。ではなぜコマンドを使用すると疎結合が保たれるのでしょうか?それはICommandというインターフェースを利用しているからです。同様にViewModelがViewのインスタンスをインターフェース経由で持てば疎結合は保たれます。したがって、これだけ見ればViewModelがViewのインスタンスを持つことに何ら問題はありません。
誤解を招かないように補足すれば、私はViewModelにViewのインスタンスを持つことを積極的に推奨しているわけではありません。イベントでコマンドを発行できないような場合(例えばListBoxのSelectionChangedイベント)、私はよく紹介されている以下のヘルパークラスを使って、イベントとコマンドを結び付けています。
WPF MVVM Helper Library (WPF + MVVM = testability)
http://www.julmar.com/blog/mark/2009/04/17/WPFMVVMHelperLibraryWPFMVVMTestability.aspx
しかし、実装方法としてはViewModelがViewのインスタンスを持つ方がはるかに簡単でわかりやすくメンテしやすいコードになります。これについてのバランスにいつも悩むわけです・・・。高いお金を出せば良い物が手に入りますが、その良い物が実際には必要以上に良いものであれば無駄遣いになってしまいます。もちろん必要以上に良いものかどうかは各人によるでしょう。
実際、SilverlightのMVVMはViewがViewModelのインスタンスを持ったり、ViewがViewModelの型情報を持っている例を見かけます。その例は以下のMSDNの記事でも見られます。
Silverlight 2 アプリケーションでの Model-View-ViewModel
http://msdn.microsoft.com/ja-jp/magazine/dd458800.aspx
ViewがViewModelの型情報を持つ例としては以下があります。SilverlightはDataTemplateのDataTypeプロパティで動的にViewを変更できないため、ResourceSelectorという仕組みを使用しているからです。
Silverlight MVVM Example
http://jmorrill.hjtcentral.com/Home/tabid/428/EntryId/339/Silverlight-MVVM-Example.aspx
以上より、MVVMの実装のパターンは実は広いということがわかります。WPFを学ぶことは大変です。WPF = MVVMのようになっていますが、MVVMはデザインパターンにすぎません。今まで通りWindowsフォームのようにイベントハンドラを使ってWPFアプリケーションを作成することも可能です。もし、初心者の方がWPF+MVVMで挫折するのであれば、一度MVVMを捨てても良いかもしれません。しかし、早くMVVMに戻ってきてください。やはりWPFにMVVMは合うと思いますし、当面の間は主流になると思うからです。それでもMVVMが難しいと感じるのであれば、ViewとViewModelの疎結合が崩れているということを知った上で、ViewとViewModelがどっぷり依存しあったコードを書いても当面はかまわないと思います。WPFにさえ慣れていない状態で、MVVMも同時に慣れろというのは初心者の方には一般的に難しいと思うからです。
結局、MVVMはデザインパターンであり規約ではありません。疎結合を保ったままMVVMを実現するというベターな実装の仕方は確かに存在します。しかしそれはあくまで一般論であり、それがベターであるかどうかは各人が置かれた環境で判断するしかないと思うのです。WPFはその設計段階であまりMVVMが意識されていなかったのでしょう。なぜなら上で述べたようにコマンドを発行できないイベントが存在し、多くの人がその壁にぶち当たるからです。
その壁をどう乗り切るかは各人の事情に合わせてで良いと思います。ただ一つ重要なのは、今実装しているパターンの欠点と他の実装のパターンの利点を知っていることです。当たり前のことですが、これはプログラミング全般に当てはまります。