問題タブ [orm]

たとえば、表示される行数に必要なデータのみを使用して、ASP.NET Web ページの gridview コントロールにデータを入力したいと考えています。NHibernate はこれをどのようにサポートできますか?

データストア内のテーブルとはまったく異なる概念クラスに O/R マッピングを行う Entity Framework プロジェクトを実際に出荷した人はいますか?

つまり、ジャンクション (M:M) テーブルを他のエンティティに集約して、ビジネス ドメインに存在する概念クラスを形成しますが、データストアでは複数のテーブルとして編成されます。MSDN で見たすべての例では、継承、結合テーブルを他のエンティティに折りたたんだり、ルックアップ テーブルをエンティティに折りたたんだりすることはほとんどありません。

ビジネス オブジェクトに対して一般的に期待されるすべての CRUD 操作をサポートする以下の例を聞いたり、見たりしたいと思っています。

1. 車両テーブルとカラー テーブル。色は多くのビークル (1:M) に表示されます。これらは、プロパティ Color を持つ概念クラス UsedCar を形成します。

2. Doctor、DoctorPatients、および Patients テーブル (多対多を形成します)。医者には多くの患者がいて、患者には多くの医者がいます (M:M)。Doctor (Patients コレクションを持つ) と Patients (Doctors コレクションを持つ) という 2 つの概念クラスを作成します。

Entity Framework で CSDL と SSDL を使用してこれを見た/行った人はいますか? CSDL は、実際に何にもマップされていなければ意味がありません。

ORM ツールを導入すると、アーキテクチャがよりクリーンになると思われますが、効率化のために、ORM ツールをバイパスして、JDBC Result Set を反復処理することが時々あります。これは、よりクリーンなアーキテクチャではなく、調整されていないアーティファクトのもつれにつながります。

これは、無効なコンテキストでツールを適用しているためですか、それともそれよりも深いですか?

ORM アプローチを完全に独り占めできるのはいつですか?

どんな洞察も大歓迎です。

背景の少し:

私の環境では、約 50 台のクライアント コンピューターと、かなり強力な SQL Server が 1 台あります。

50 クライアントすべてが常にデータにアクセスしているデスクトップ アプリケーションがあります。

プロジェクトのデータ モデルは、明確性、効率性などのさまざまな理由から、多くの再編成を経てきました。

私のデータモデルの歴史

1. JDBC が直接呼び出す
2. Pojo 間の関係のない DAO + POJO (基本的に JDBC をラップ)。
3. 遅延読み込みを実装する POJO 間の関係を追加しましたが、DAO 間の呼び出しを非表示にするだけです
4. Hibernate の時流に飛び乗ったのは、Hibernate の時流に飛び乗ったのは、Hibernate がデータ アクセスをいかに「シンプル」にするか (POJO 間の関係が些細なものになった) を見てからでした。
5. セッションを長期間開いたままにしておくのはデスクトップアプリケーションだったので悪夢だったので、最終的には多くの問題を引き起こしました
6. Hibernate を使用しながら、DAO カーテンの背後で直接 JDBC 呼び出しを行うことができる、部分的な DAO/Hibernate アプローチに戻りました。

私は、ストアド プロシージャとパラメーター化されたクエリを組み合わせた独自の SQL アクセス コードと、ADO.NET グランジを最小限に抑えるために作成した小さなラッパー ライブラリを作成することに成功しました。これは過去に私にとって非常にうまく機能しており、かなり生産的でした.

私は新しいプロジェクトに向かっています.古い学校のものを私の後ろに置いて、ORMベースのソリューションを掘り下げる必要がありますか? (NHibernate と EF の間には、高度な概念の大きな違いがあることはわかっています。ここではそれについては触れたくありません。議論のために、LINQ を古い学校の代替手段とひとくくりにしましょう。)私が知っている（そしてかなりよく知っている）ものに対するORMタイプのものの実世界への適用に関するアドバイス。

古い学校の ADO.NET コードまたは ORM? 曲線があると確信しています。曲線には価値のある ROI がありますか? 私は不安で学びたいと思っていますが、締め切りがあります。

JPOX や Hibernate などの ORM ツールを使用してデータベース スキーマをアップグレードするための一般的なソリューションを探しています。プロジェクトでそれをどのように行いますか?

私の頭に浮かんだ最初の解決策は、データベースをアップグレードするための独自のメカニズムを作成し、SQL スクリプトがすべての作業を行うことです。ただし、この場合、オブジェクト マッピングが更新されるたびに新しいスクリプトを作成することを覚えておく必要があります。また、マッピングを定義して ORM ツールにすべての作業を任せる代わりに、低レベルの SQL クエリを処理する必要があります...

そこで問題は、それを適切に行う方法です。ツールによっては、このタスクを簡素化できるかもしれません (たとえば、Rails にはそのようなメカニズムが組み込まれていると聞きました)。そうであれば、次の Java プロジェクトでどの ORM ツールを選択するかを決めるのを手伝ってください。

私たちは職場でのプラクティスのいくつかを見直しています。現在検討しているのは、Flex ベースのクライアントと .NET Web サービスで通信を行うための最良の方法です。

私たちの典型的なアプローチは、最初に要件に基づいて対話をモデル化し、いくつかの XML メッセージをモックアップしてサニティ チェックし、それらを XSD に変換し、最後に XML との間でシリアル化するクラスを両端に構築することです。

これは、データベースにヒットするまで問題なく機能し、テーブルの結合などによって、クライアント側で単純化したすべての作業が台無しになり始めます。

LINQ to SQL やその他の OR マッパーを使用してこれを解決しようとしましたが、より深刻な問題を引き起こすことなく実際に問題を解決するものはありません。

RDBMS を単なるオブジェクト ストアとして扱わずに、膨大な量の変換コードを記述せずに複雑なデータ要件を処理するより良い方法はありますか?

私が探している魔法の弾丸は、結合テーブルとは何か、それを処理する方法を知っているものであり、Flex 用に「適切な」シリアル化された XML を生成し、強力な .NET タイピングを保持できるものだと思います。

各メソッドに必要な SQL を分析し、ストアド プロシージャを生成して使用できればボーナス ポイントです。しかし、それはおそらくあまりにも多くを求めています:)

「テーブルの結合」に注意してください。

これの定義は、2 つ以上の外部キーを独自の主キーとして持つテーブルがある場合です。

例えば：

Flex クライアントが Photo オブジェクトを取得すると、すべてのタグのリストも取得する場合があります。したがって、次のようになります。

代わりに、私が見た OR ツールは次のことを提供してくれます。

NHibernate を ORM として使用するアプリケーションがあり、データへのアクセス方法が原因でパフォーマンスの問題が発生することがあります。NHibernate のパフォーマンスを改善するには、どのようなことを行うことができますか? (回答ごとに 1 つの推奨事項に制限してください)

Linq toEntitiesやlinqtoSQLよりも、NHibernate、さらにはCastleでより多くのことができることがわかりました。

私は夢中ですか？

ORM と QuerySet API を使用して Django でマルチジョイン クエリを実行するための最良および/または最速の方法は何ですか?

1 つの applicationContext.xml ファイルがあり、Spring ミドルウェア カスタム アプリケーションで構成された 2 つの org.springframework.orm.jpa.JpaTransactionManager (それぞれが独自の永続ユニット、異なるデータベースを持つ) があります。

TransactionStatus のコミット、保存、およびロールバックをいじらないように、アノテーション ベースのトランザクション (@Transactional) を使用したいと考えています。

同僚は、複数のトランザクション マネージャーがあると、コンテキスト ファイルが正しく構成されていても、これを行うと何かが混乱すると言っていました (参照は正しい永続化ユニットに移動します)。誰か問題を見たことがありますか?

あなたの構成では、2 つのトランザクション マネージャーがありますか? txManager1 と txManager2 はありますか?

それが、トランザクション マネージャーである 2 つの異なる Spring Bean である JPA で私が持っているものです。