0

Locationモデルクラスがあります。抽象クラスPersisterがあります。抽象クラスには、MySQLPersisterとMongoDBPersisterの2つの実装があります。理由は、必要なときにいつでもMySQLとMongoDBのどちらを使用するかを切り替えることができるようにするためです。両方を同時に使用していないことに注意してください。柔軟性を高めるためだけに。

問題は、LocationモデルクラスがModelを拡張することです。MySQLはplay.db.jpa.Modelをインポートする必要があります。MongoDBはplay.modules.morphia.Modelをインポートします。これは問題になります。なぜなら、切り替えるたびに、Locationモデルクラスを変更する必要があるだけでなく、2つのライブラリのモデルのメソッドが異なるため、Persisterの実装のコードも変更する必要があるからです。

たとえば、JPAの使用からMorphiaに変更する場合は、MySQLPersisterのコードをコメントアウトする必要があります。Model.find（）。fetch（）はJPAでIterableを返し、JPAをインポートするとMorphiaのModel.find（）。filter（）。asList（）は存在しません。

この問題を解決するにはどうすればよいですか？ジェネリックモデルクラスと、各データベースをインポートする2つの同一のモデルクラスを作成したくありません。これは重複が多すぎます。

基本的に、play-morphiaとplay-jpaのデザインは柔軟性がないと思います。

JPA                             PlayMorphia
play.db.jpa.Model           >   play.modules.morphia.Model
javax.persistence.Entity    >   com.google.code.morphia.annotations.Entity

play.db.jpa.Model両方がより一般化されたクラスplay.modules.morphia.Modelから拡張されていればもっと良かったでしょう。Modelこのようにして、両方のデータベースを実装する場合にモデルを変更する必要はありません。

ありがとう！説明が明確でない場合はお知らせください。

4

2 に答える 2

0

永続層の上に別の抽象化層を使用してみます。抽象レイヤーは、アプリケーションのニーズに合わせて実装に依存しないメソッドを提供する必要があります。次に、レイヤーは、呼び出しを実際のフレームワークに依存する永続レイヤーの実装（jpa.ModelやMorfia.modelなど）に委任する必要があります。

これはあまり重複していませんが、オブジェクト指向プログラミングの良いユースケースです:)

于 2012-06-05T16:44:28.833 に答える
0

私は次の解決策を決定しました：

MySQLPersisterとMongoDBPersisterに内部Locationクラスを作成し、それらを使用してORMを実行し、データベースにクエリを実行します。次に、内部Locationクラスによって入力された結果を、一般的なフロントエンド向けのLocationBeanに変換します。基本的に、2つのパーシスター内の内部クラス内でLocationモデルを2回複製しました。

このように、データベースを切り替えたい場合は、新しいMySQLPersisteR（）と新しいMongoDBPersisterのどちらを初期化するかを変更する必要があります。新しいデータベースを実装する必要がある場合は、ORM用の独自の内部クラスを使用してLocationPersisterを再度拡張する必要があります。

于 2012-06-05T19:20:04.583 に答える