ASP.NET Web アプリケーションではステートの管理を3段階で行っている。
１）Controlなどクライアント側でが持つ状態をViewStateとして保持しPostBackを利用する。
２）セッション毎にSessionStateとしてサーバー側に保持する。
３）複数セッションで共通に必要となる情報をApplicationStateとしてサーバー側に保持する。
サーバーが複数台ありどのサーバーにリクエストが振り分けられるかわからない場合などでは、SessionStateはデータベースに保持され、Sessionが完結した場合に消去される。
ただし完結しないままWebを閉じてしまったりする場合があるのでデータベースのSessionStateは定期的に期間超過した分を消去する必要がある。
つまり、ASP.NET Web アプリケーションではクライアントとサーバーが一体となってステートを保持する仕組みとなっている。
この間サーバーへのアクセスが入るので時間がかかるためサーバーの高速応答がストレス減少のキーとなったりする。
Silverlightアプリケーションでは サーバーにサービスを使ってステートを保持させることは可能であるが一般には行われない。
Silverlightアプリケーションでは 画面が移り変わっても内部でステートを保持しユーザーの操作が完了した場合にサーバーにサービスを使って保存する方がユーザーのストレスが少ないシステムとなる。
それではステートを保持させる機構はどこが持つのだろうか、Microsoft の Silverlight Developer Center の記事「Visual Studio 2010/Silverlight 4 ソリューション サンプル (MVVM) 編 ~ Silverlight 4 + WCF RIA Services + MVVM ~」では ViewModel に保持していて、ViewのコードビハインドがModelを保持していて（DomainContext）操作している（WCF RIA Services）。
この記事はマイクロソフトの方がMVVMパターンを使ってサンプルを作ってくれている画期的な記事だと思うが、私の考えるMVVMのあり方とはかなり違っている。
私の考えでは、ViewがViewModelを飛び越えてModelを直接操作するのではなく、コマンドを利用してViewがViewModelを呼び出してViewModelがModelを操作したほうがいいと思っている。
AAG2.0 の分類ではViewとViewModelはプレゼンテーション層のUIコンポーネントとプレゼンテーションロジックコンポーネントに該当する。
Silverlightアプリケーションでは一般にサービス層はなく、データ層は分離ストレージ用のデータアクセスコンポーネントとWCF RIA Servicesを扱うサービスエージェントとなる。
Modelはビジネス層とデータ層を意味することになる。
ユーザー入力によりViewで発生したステートはViewModelを通しビジネス層のアプリケーションファザードやビジネスコンポーネントを経てビジネスエンティティに蓄えられる。
画面遷移などによりViewで必要な情報もViewModelのリクエストでビジネス層のアプリケーションファザードがビジネスコンポーネント経由でデータ層のサービスエージェントを操作して取得しビジネスエンティティに蓄えられ、ビジネス層のアプリケーションファザードがViewModelに返却する。
ViewModel間の連携がLocatorを使って密に行われるのであればビジネス層のビジネスエンティティのプロパティ変更をViewModelで検知する必要がなく、ViewModelが配信が必要と思うViewModelの公開メソッドを呼ぶだけである。
ViewModelとビジネスエンティティのライフサイクルの違いやどのプロパティが変更されてもいちいち反応するPropertyChangedイベントのロスの大きさを考えるとプロパティ変更を層を超えてまでViewModelで検知することはお勧めしたくない。
結論としてはSilverlightアプリケーションではMVVMパターンでステートを保持するのはViewModelとModel（ビジネス層のビジネスエンティティ）である。
