orm - コードジェネレーターまたは ORM?

Question

データアクセスレイヤーについて何を提案しますか? Entity Framework や Hibernate などの ORM または Subsonic、.netTiers、T4 などのコード ジェネレーターを使用していますか?

Answer 1

私にとって、これは簡単です。コードを生成します。

根本的な誤謬が大きくなっているので、ここでは少し話題から外します。誤謬は、これらのORMフレームワークがオブジェクト/リレーショナルインピーダンスの不一致を解決することです。この主張は素顔の嘘です。

オブジェクト/リレーショナルインピーダンスの不一致を解決する最善の方法は、OOPを排他的に使用してオブジェクトデータベースを使用するか、リレーショナルデータベースのイディオムを排他的に使用してOOPを無視することです。

「すべてがテーブルである」という抽象化は、「すべてがクラスである」という抽象化よりもはるかに強力です。オブジェクトモデルではなくデータベースにコーディングする場合、必要なコードと知的労力が少なくて済み、コードが高速になります。

私にはこれは明らかなようです。アプリケーションがデータ駆動型の場合、コードもデータ駆動型である必要がありますか？しかし、これは非常に物議を醸していると言うことです。

ここでの中心的な問題は、データベースと組み合わせて使用​​すると、OOPが非常にリークの多い抽象化になることです。OOPのイディオムに記述されたときに完全に賢明に見えるコードは、コードがデータベースで生成するトラフィックを見ると完全に異常に見えます。その混乱がパフォーマンスの問題になると、OOPが最初の犠牲者になります。

これを解決する方法は本当にありません。データベースはデータセットを処理します。OOPはクラスのインスタンスに焦点を合わせています。二人と結婚しようとすると、常に離婚に終わります。

したがって、あなたの質問に答えるには、クラスを生成し、それらが基礎となるデータベース構造を可能な限り厳密にマップするようにする必要があると思います。

Answer 2

おそらく物議を醸すかもしれませんが、ADO.NET の配管にコード ジェネレーターを使用することは根本的に間違った問題を解決していると常に感じていました。

ある時点で、接続文字列、SqlCommands、DataAdapter などについて学習してすぐに、次のことに気付きます。

1. そのようなコードは醜いです
2. 書くのはとても退屈です
3. 手動で行っている場合、何かを見逃すのは非常に簡単です
4. データベースにアクセスするたびに繰り返す必要があります

では、解決すべき問題は「同じことを何倍も速く行う方法」でしょうか。

私はノーと言います。

コード ジェネレーターを使用してこのプロセスを高速化するということは、ビジネス クラス全体 (ビジネス ロジックから分離している場合はデータ アクセス層) 全体に大量のコードが存在することを意味します。

そして、一般的に何かをしたい場合 (たとえば、ストアド プロシージャの使用状況を追跡するなど)、必要な機能がまだコード ジェネレーターにない場合は、コード ジェネレーターをカスタマイズする必要があります。たとえそうなったとしても、常にすべてを再生成する必要があります。

どんなに速くできるとしても、何回もではなく一度だけやるのが好きです。

そこで、パラメーターの追加、接続のセットアップとクローズ、トランザクションの管理、およびその他の優れた機能を理解する独自のデータ アクセス クラスを開発しました。これは 1 回だけ記述する必要があり、データベース関連の処理が必要なビジネス オブジェクトからのメソッドの呼び出しは、1 行のコードで構成されます。

アプリケーションでマルチスレッド データベース アクセスをサポートする必要が生じたとき、変更が必要だったのはデータ アクセス クラスだけで、すべてのビジネス クラスは既に行っていたことを実行するだけでした。

Answer 3

正解はありません。プロジェクトによって異なります。Simon が指摘しているように、アプリケーションがすべてデータ駆動型である場合、ドメインのサイズと複雑さによっては、非 oop パラダイムを使用することが理にかなっています。システム内で XML メッセージを渡すトランザクション スクリプト パターンを使用して、システムを構築することに多くの成功を収めました。

しかし、このシステムは、アプリケーションのサイズと複雑さが増すにつれて (5 または 6 の Web、いくつかの Web サービス、大量の COM+ コンポーネント、レガシーおよび .net コード、800 以上のテーブルを持つ 8 以上のデータベース 4,000 以上)、5 ～ 6 年後に故障し始めました。手続き）。誰も何が何だか分からず、複製が横行していました。

OOP よりもメンテナンスを軽減する方法は他にもあります。ただし、非常に複雑なドメインがある場合は、ビジネス ルールを適切にカプセル化されたコンポーネントで表現できるため、豊富なドメイン モデルを使用するのが理想的です。

質問に答えるには、可能であればコード ジェネレーターを避けてください。コード ジェネレーターは災害のレシピですが、コード生成を使用する場合は、生成されたコードを変更しないでください。また、開発者が新しく生成されたコードを簡単に取得できる適切なプロセスを用意してください。

次のいずれかを使用することをお勧めします。ORM または軽量の DAL をハンドロールします。私は現在、手巻きの DAL から nHibernate にプロジェクトを移行しており、多くの成功を収めています。ただし、どちらかのオプションを使用するオプションがあるのが好きです。さらに、懸念を適切に分離する場合 (プレゼンテーションからのビジネス層からのデータ アクセス)、1 つのオブジェクトは ORM であるが、別のオブジェクトは手動でロールされる Dao (データ アクセス オブジェクト) と通信する単一のサービス層を持つことができます。仕事に最適なツールを適用できるので、この柔軟性が気に入っています。

私の DAL はほとんどの ADO.Net コードを抽象化しますが、データ リーダーをオブジェクトまたはオブジェクトに取り込んでパラメーターを作成するコードを記述する必要があるため、私は手巻きの DAL よりも nHibernate が好きです。

Answer 4

特に C# では、基本的なデータ オブジェクトに機能を追加するために拡張クラスを利用できます。

Answer 5

これを言うのは嫌いですが、場合によります。ニーズに合った ORM ツールが見つかったら、それを選択してください。アプリケーションの開発中に、小さなステップで独自のシステムを作成しました。私たちは C++ を使用していますが、ツールはそれほど多くありません。最終的にはデータベースの XML 記述になり、そこから SQL 生成スクリプトと基本的なオブジェクト レイヤーとメタデータが生成されました。

下調べを行い、これらのツールを評価すると、ニーズに適したツールが見つかります。