4

私が現在取り組んでいる次の簡略化されたドメイン モデルを検討してください。

case class Product(val id : Long, val name : String, product : Option[Product], category : Option[ProductCategory])

case class Price(val id : Long, val amount : Double, val conditions : Seq[Condition])

trait Condition {
  def isTrue(product: Product):Boolean
}
case class ManufacturerNameCondition(val id : Long, val name : String){...}
case class DateCondition(val id : Long, val validFrom : Date, val validTo : Date){...}

このモデルは何を表していますか?

これは単純な価格サービスを表しており、製品または製品カテゴリに対して複数の価格を定義できます。製品の最終的な価格は、一致するすべての価格と関連する条件を確認して決定されます。たとえば、製品の通常価格と、DateCondition があるため、今日だけ有効な追加価格が 1 つある場合があります。

私の問題は何ですか？ 価格は複数の条件に関連付けることができます。各状態は、別のタイプの場合があります。だから私は、これを Slick (= ポリモーフィックな関係) でどのように解決すべきか自問自答しています。基本的に、関連する条件とともに価格を取得する DAO のようなインターフェイスが必要です。

私の質問:

  1. このモデルを Slick で実装することは可能ですか? （おそらくそうだ）
  2. ポリモーフィックな関係: この問題を Slick で解決するのは良い考えですか? Slick は、オブジェクト リレーショナルの不一致を克服したいと述べており、ここでは、このモデルでフレームワークと戦おうとしているような気がします。Slick は、このようなオブジェクト指向のアプローチではうまく機能しませんか? 別のアプローチを選択する必要がありますか?

Plz 注: はい、私が試したことを示すコードはありませんが、現在、探す方向が必要です。現在、私はどういうわけか迷っています:-)

4

1 に答える 1

5

Slick は、オブジェクト リレーショナル インピーダンスの不一致を克服するのではなく、回避します。Slick でモデル化する方法の答えは、基本的に、(ORM ではなく) リレーショナル モデルで最適にモデル化する方法です。Slick が SQL の上に追加したのは、タイプ セーフ、スカラ セマンティクス、および構成可能性です。つまり、正常に再利用できる関数とコード フラグメントを作成する機能です。継承が本当に必要な場合は、自分でマッピングする必要がありますが、Slick のコンポーザビリティにより、それほど面倒なことはありません。たとえば、それが何であるかを示すkindor列があります。role次に、単一テーブルの継承<>を行い、適切なサブクラスを生成する Slickのマッピング演算子に関数を提供します。または、クラステーブルの継承を行います、すべてに参加して同じことを行います。kindまたは、 aを指定して必要な結合のみを行う関数を作成します。ライブラリに配置して、他の人が再利用できるように github に配置することもできます:)。

于 2014-03-21T17:12:36.607 に答える