0

私はこのように設計されたアプリケーションを維持しています：

messy code --abuses--> simplePoco (POCO data capsule)

データカプセルは、多くのゲッターとセッター（プロパティ）を備えた単純なクラスです。DIフレームワークを使用し、一貫してIoCコンテナーを使用してデータカプセルのインスタンスを提供します（幸運なことに！）。

問題は、「変更通知」メカニズムを導入する必要があることです。simplePoco

messy code --abuses--> simplePoco 
               |
               V
         changes logger,
         status monitor
     (I wanna know about changes)

私にはいくつかの選択肢があります：

  • を導入しIPoco、厄介なコードを変更してsimplePoco、速度を上げるために、またはnotifyingPoco変更通知（選択的に遅い）が必要な場合に使用できるようにしますか？また ...

  • すべてを仮想化し、自分のカスタムnotifyingPocoクラスをsimplePoco（さらに遅く）上にロールしますか？

  • わからないデザインパターン？

これはクライアント/サーバーシステムですが、サーバー部分を変更しているだけなので、可能であれば、 厄介なコードやクライアントコード（シリアライザーとリフレクション、恐ろしい忍者のものがあります...）には触れたくないです。誤って何かを壊してしまいます。

インターフェイスを使用すると、JITがgetter / setterへの呼び出しをインライン化できなくなりますか？

simplePocoインスタンスがひどく悪用されていることを考えると、最善の方法は何ですか？

4

1 に答える 1

3

あらゆる種類の仮想呼び出し（インターフェイス上またはクラス上で直接-すべてのインターフェイス呼び出しは仮想です！）は、CLRJITによってインライン化されません。thisとは言うものの、インターフェース呼び出しは、常にリモート/プロキシされる可能性のあるパスを通過する必要があり、関数の本体に入る前にクラスの先頭を指すようにポインターをシフトする必要があるため、少し遅くなります。クラスメンバーへの直接の仮想呼び出しはシフトを行う必要はなく、クラスがから派生していない限り、MarshalByRefObjectプロキシチェックにヒットしません。

とはいえ、これら2つのパフォーマンスの違いはごくわずかであるため、おそらくそれらを無視して、代わりに設計のクリーンさと実装の容易さに焦点を当てる必要があります。

于 2009-08-14T20:30:35.033 に答える