nhibernate - 関係が定義されていないデータベースで ORM を使用していますか?

Question

ある程度定義された主キーを持つ100以上のテーブルで構成されるデータベース（MSSQL 2005）を考えてみましょう。テーブル間には「関係」がありますが、これらは外部キー制約では強制されません。

私が扱っている典型的なタイプのテーブルの次の単純化された例を考えてみましょう。User テーブルと City テーブル、Province テーブルの間には明確な関係があります。ただし、重要な問題は、テーブルのデータ型と命名規則に一貫性がないことです。

User:
    UserRowId [int] PK
    Name [varchar(50)]
    CityId [smallint]
    ProvinceRowId [bigint]

City:
    CityRowId [bigint] PK
    CityDescription [varchar(100)]

Province:
    ProvinceId [int] PK
    ProvinceDesc [varchar(50)]

このデータ ソースを使用するアプリケーション (ASP.net MVC) を MVC ストアフロントと同様の設計で書き直すことを検討しています。しかし、私は概念実証段階を経ており、これは私が遭遇したつまずきの 1 つです。

1. 簡単に使用できる ORM の選択に関して、どのようなオプションがあり、その理由は何ですか?

2. ORMを検討する必要がありますか? （私がこれを尋ねる理由は、ほとんどの説明とチュートリアルはすべて、比較的きれいに設計された既存のデータベース、または私のものと比較して新しく作成されたデータベースで機能するためです。したがって、この問題を解決する方法を見つけるのに非常に苦労しています）

3. 既存の SQL クエリは大量にありますが、データマッパー (IBatis.net など) の方が適しているでしょうか? 簡単に変更して動作させ、既に行った投資を再利用できるからです。

SO でこの質問を見つけました。これは、ORM を使用できることを示していますが、これはマッピングの問題であるという印象を受けますか?

注: 現時点では、オブジェクト モデルは存在しなかったため、明確に定義されていません。既存のシステムはほとんどすべてを SQL で処理するか、機能を完成させるために非常に複雑で多数のクエリで構成されていました。私は初心者であり、ORM と MVC に関する経験はまったくありません。したがって、これは私が経験している素晴らしい学習曲線です。

Answer 1

私はベンに同意します。

私はLAMPスタックでこの状況にありました。古い汚れたコード化されたウェブサイトは、ゼロから始める必要がありました。それは文字通り私が見た中で最悪のデータベースであり、行ごとに盲目的な SQL 実行が相まっていた.

仕事？そのすべての SQL を非常に迅速に取り除き、抽象化に置き換えます。どのORM？既存の ORM を使用して悪いデータベース (実際にはほとんどのデータベース) に適合させることは、振り返ってみると悪いニュースであることがわかりました。これはORMの問題だと思います.ORMはデータベース/ストレージの問題をアプリケーションに近づけます...遠くではありません。

私の解決策:既存のデータベースの状態のみを使用して、何が起こっているのかを解明するリフレクティブ ORM。すべての選択、挿入、更新、および使用されていないビュー/保存された手順は、厄介なデータベースをマスクします。これは、厳しい SQL を書き換えるだけの linq 風の API によって強化されています。約 100klocs の SQL ステートメントを 2klocs 未満に煮詰めました。

長所：ビューと手順の背後にあるより良い構造にデータベースを徐々に移植できます。IMHOこれは、SPとビューが提供する抽象化を最大限に活用して、すべてのデータベースを編成する方法です。テーブルに対して直接単一の SQL ステートメント (または SQL を装った ORM) を見たくありません。

それが私の話です。最初にデータベースを書き直したり、ORM を混同して物事をより複雑にしたりせずに、既存のくだらないデータベースの上に素敵な抽象化をスロット化する過度に設計された方法。

間違いなくハックですが、うまく機能するので、データベースを最初から設計できるプロジェクトで使用しています;)

Answer 2

ひどいスキーマ設計でこの問題に直面しました (主キーがランダムにあり、外部キーがまったくない、設計が不適切なテーブル - めちゃくちゃです)。

私たちはテクノロジーを選択する余裕があり、MVC2 フロントエンド (あなたの質問とは関係ありません) に移行し、2 つの開発者が分割されました。

急いで付け加えておきますが、ドメイン モデルに何を求めているかについて強い考えがあり、それを最初にモデル化した (データベースに制約されたくない) ため、スキーマの観点から見た「ユーザー」オブジェクトは実際には 5 つのテーブルにまたがっていました。 、ドメイン モデルが貧弱にならないように多くのビジネス ロジックをカプセル化し、ユーザー オブジェクトに満足したら、ORM のプラグインを試みるプロセスを開始しました。

両方のケース (NH と EF4) でためらわずに言うことができます。私が最も深く関わった EF4 の例を紹介します。他の人はこれらを他の ORM に関連付けることができるかもしれません。

プライベート セッター

いいえ - EF4 との生活ではありません。プロパティはパブリックである必要があります。回避策があります (たとえば、DB から入ってくるプロパティのラッパーを作成するなど)。

列挙

繰り返しますが、いいえ-ラッパーの概念と、DBからモデルの列挙型へのルックアップintを取得しようとする「マッピング」がありました。

結果

ユーザーのマッピングを完了するポイントに到達するまで、しばらくの間、両方のアプローチを使い続けましたが、その結果、あまりにも多くの方法でドメイン モデルを妥協する必要がありました。

その後、私たちはどこに行きましたか？

独自のマッピング レイヤーを使用した Linq to SQL。Dto オブジェクトを Dal レイヤーに取り込んで (指定したとおりに) Domain モデルにマップするマッピング レイヤーを自分で作成したことは、まったく素晴らしいことです。

ORM の調査で幸運を祈ります。もしもととなる適切なスキーマがあれば、再調査したいと思います。

乾杯、テリー

Answer 3

既存のスキーマを維持し、それをより構造化された orm パターンに変換する作業は、おそらく膨大で複雑なものになるでしょう。システム全体を書き直して古いものを廃止する場合は、おそらくlinq2sqlを使用して、新しいデータベースと一連のクラスを作成するデータモデルを考案し、データ移行スクリプトを記述して古いスキーマから新しいスキーマにデータを移動します. そうすれば、複雑で面倒なコードはすべて移行され、構造化されたクラス モデルと不適切に設計されたデータベースとの間の複雑なマッピングを維持および管理する必要がなくなります。