2

現在のアプリケーションでは、データベースの操作にスマートオブジェクトスタイルを使用しています。代わりに、PetaPocoへの移行の実現可能性を検討しています。機能を確認すると、属性を追加してオブジェクトをCRUDしやすくすることができます。これらの属性を追加すると、注意すべきマイナスの副作用がありますか？

これらのデコレータを使用しない理由を見つけた人はいますか？

4

2 に答える 2

2

POCOオブジェクトインスタンス自体を直接使用しますか？なし。

少なくとも私が知っていることではありません。Jon Skeetは、コンパイラの内部動作を徹底的に知っているため、より多くの情報を提供できるはずです。したがって、コンパイル後にこのメタデータがどうなるかを正確に知っています。

これらに間接的に関連する他の影響

もちろん、これらの宣言型属性にアクセスする場合は、通常は遅いプロセスであるリフレクションを使用して読み取られるため、影響があります。

ただし、PetaPocoはスマートライブラリであり、これらを1回だけ読み取り、コンパイルしてキャッシュするため、ここで心配する必要はありません。そのため、ペナルティは1回だけで、その後は驚異的なパフォーマンスが得られます。コンパイルされたコードを使用するためです。

パフォーマンスに関連しない影響

クラス/プロパティ/メソッドに属性（任意）を配置することにより、このクラスを使用する特定のエンジンにコードをバインドします。これは、この特定のエンジンがコードを理解するためのディレクティブであるためです。

PetaPoco属性の場合、これは、クラスをPetaPocoで使用できるが、他のDAL（EFなど）でも使用できないことを意味します（EF Code Firstは、属性に対してまったく同じアプローチを使用します）。

2番目の意味は、バックエンドデータベースに関連しています。PetaPoco属性で定数マジックストリングとして提供されているテーブル、列、またはその他の部分の名前を変更した場合は、後でこのストリングも変更する必要があります。これは、データベースの変更を行うときに徹底する必要があることを意味します...

于 2012-04-12T06:07:42.017 に答える
2

欠点の1つは、「ドメイン」レイヤーと「データ」レイヤーの分離が崩れることです。これは、PetaPocoファイル（データロジックを含む）を、データレイヤーに対する知識や依存関係を実際に持たないドメインクラスに導入するためです。

単一プロジェクトのMVCアプリなどを実行している場合は、両方にModelsディレクトリを使用してもかまいませんが、重要で分離されたアプリの場合は、2つのPetaPocoファイルを用意するか、基になるデータについて「あまり知らない」ようにモデルに注釈を付けるためにファイルを作成するか、テーブルや主キー名をあちこちで指定する必要があります。

于 2012-05-22T19:33:53.657 に答える