そもそも２つ画面で同じデータを参照しているとき、そのオブジェクトのインスタンスは同一であるべきなのか？異なるべきなのか？
単に画面機能が参照であれば同一でもいいけど、更新系（ステータス）だとそうもいかない？
そもそも、そんな画面では「排他制御をかけるべき」という話もない訳ではない。
排他制御の話は置いといて。
.NETのEntity Framework上では、自動生成されるエンティティ・クラス（テーブルに対応する構造体的なクラス）と、そのエンティティ・クラスのオブジェクトを保持するロジックを実装したクラスで、内部構造的にはTransactionScriptパターン的なモデルになりそう。
第6回 EF4によるN層アーキテクチャと自己追跡エンティティ【前編】 − ＠IT
ここの「図1 .NET Frameworkでの3層アーキテクチャの例」のビジネス層（エンティティクラスとかビジネスロジック）って、狭い意味でTransactionScriptパターン的なモデルって見える。
外部のパッケージ、コンポーネント、サブシステムレベルのようなレイヤから見れば、それはカプセル化（内部の持ち方）という話で終わらせるとして。
とは言え、オブジェクトとしての値を参照する時に、自動生成されるエンティティ・クラスのオブジェクトを参照するのは個人的には好きくない。
＃委譲したいけど面倒くさそうｗ
んで、インスタンスのスコープという観点では、上の図1のビジネス層を実装したクラスとしてのオブジェクトのスコープは？というところが見えてないのか。
ドメイン層に最適なアーキテクチャを考える − ＠IT情報マネジメント
ここのDomainModelパターンのサービス層のレイヤ（図２）とTransactionScriptパターンのドメインモデル（図１）の役割としての対応付けができれば、もう少し明確な判断ができそうな気がする。
＃そもそもサービスってなんだよ？って話もあるしｗ
実装レベルでは、オブジェクト変数として値を持つ場合においては、Singletonでスレッドセーフなモデルを実現しようと思えば、Javaで言うところのThreadLocal、.NETで言うところのThreadStaticで属性なりの値を保持しなければならない、という技を駆使して適用すればよいという風になるのかな。
なので、上記のビジネス層を実装したクラスが、自動生成されるエンティティ・クラスのオブジェクトをThreadStaticで持ってればいいじゃん、的な話のような気もしてみたり。
