2

モデル内のエンティティを表すPOJOにOID (通常はデータベースの行識別子)を含めることの長所と短所を説明できますか?

実際、私はイコール/ハッシュコードなどに関連する問題について話しているのではありません。私の問題をもっとよく説明するべきでした(私の悪い:) )...

ビジネス オブジェクト (製品、カタログなど) を表すエンティティ クラスがいくつかあります。場合によっては「ビジネス ID」があります。たとえば、Product は一意の ProductId (id、type、repository の 3 つのフィールドがあります) で見つけることができます。

私たちのデータベースでは、Product テーブルには 3 つのビジネス列 (id、type、repository) に加えて代理主キー列 (OID) があり、外部キーの参照を容易にし、結合句を少なくしています。

Product/ProductId クラスは、他のアプリケーションに公開する API の一部です。たとえば、次のように呼び出すことができます。

productManager.findProductById(ProductId productId);

問題は、クライアントが ProductId 識別子を使用することが期待されていることを知って、OID を Product または ProductId クラスに含める必要があるかどうかです。

長所：

  • OID を使用して、次のような別のルックアップを行うことができます

    Product p = productManager.findProductById(ProductId productId);
Catalog c = productManager.findAllCatalogsContainingProduct(p.getOid());

アプリケーションで ProductId を使用して多くのルックアップを行うことに慣れているため、データベースへのラウンドトリップのたびに、ProductId に一致する OID を見つける必要がなくなります。

短所：

  • OID をクライアントに公開しました (ビジネス キーの代わりに OID を使用しないことを祈りましょう!!)

他の長所と短所をリストできますか？

4

2 に答える 2

1

データベース行識別子 = 主キー? そうでない場合は、POJO を対応するデータベース行に関連付けることができません。

製品とカタログを取得するための標準的な SQL の方法は、結合を行うことです。たとえば、私の DAL では次のことができます。

SearchCriteria sc = new SearchCriteria();
sc.AddBinding("ProductId", productId);
List<Entity> Products = SQL.Read(sc, new Product(new Catalog());

また

List<Entity> Products = SQL.Read(sc, new Catalog(new Product());

この方法では、発信者に何も明らかにする必要はなく、ラウンドトリップも必要ありません。

于 2008-12-31T17:34:31.900 に答える
0

equals（）またはhashCode（）の実装が識別子に基づいている場合、最初はnullであり、オブジェクトが永続化されると後で変更される可能性があるため、問題が発生する可能性があります。下記参照：

http://java.sun.com/javase/6/docs/api/java/util/Set.html

注：可変オブジェクトをセット要素として使用する場合は、細心の注意を払う必要があります。オブジェクトがセット内の要素であるときに、等しい比較に影響を与える方法でオブジェクトの値が変更された場合、セットの動作は指定されません。この禁止の特殊なケースは、セットがそれ自体を要素として含むことは許可されないということです。

hashCode（）の実装が識別子に基づいており、equals（）がその比較でhashCode（）を使用すると仮定します。オブジェクトをセットに追加し、その識別子がnullの場合、等しい比較は一方向で実行されます。その後、オブジェクトをセットに永続化すると、その識別子の値が変更される可能性があり、equals（）およびhashCode（）の動作が変更されます。これは、上記のようにセットの「契約」を破ります。

これは少しエッジケースですが、注目に値するものです。

于 2008-12-31T17:38:48.350 に答える