0

私はビジネス/エンティティクラスのレイヤーの白紙の状態から始めていますが、既存のデータソースを使用しています。通常、これは簡単なことであり、Entity Frameworkを起動し、DBにポイントして、1日と呼びますが、当面は、サードパーティベンダーのデータソースから実際のデータを取得する必要があります...

  1. 一般的なODBCプロバイダー(SQLではない)からのみアクセスできます
  2. 構文、命名が非常に悪く、場合によっては、どこにでもデータが重複している
  3. 100をはるかに超えるテーブルがあり、これらを組み合わせると、データの1,000列/プロパティの近くになります。

このDBからの読み取り専用が必要なだけなので、更新/挿入/削除をサポートする必要はありません。アプリケーションの実行ごとに1回、「ダーティ」データをクリーンなエンティティに抽出する必要があります。

データベースを、すてきでクリーンな、名前の付いたエンティティクラスから可能な限り分離したいと思います。

次のような良い方法はありますか?

  1. DBテーブルから初期エンティティクラスを生成しますか?(そうすれば、クラスのプロパティの名前を変更して修正し、最初から始めるのではなく、サニタイズすることができます。)
  2. 1000個のプロパティセットを記述せずに、DBからのデータを私の素敵でクリーンなクラスにマップしますか?

編集:ここでの主な目標は、疑似ORMを考案することではなく、既存のコードに基づいて既存のコードを可能な限り生成し、必要に応じて微調整して、多くの手作業を排除することです。 -集中的なクラス作成タスク。

4

2 に答える 2

3

エンティティの構造をより細かく制御するために、データベーススキーマからクラスを自動生成することは避けたいと思います。データベース構造にとって意味のあることは、クラス構造にとって必ずしも意味があるとは限りません。サードパーティまたはレガシーシステムの場合、データベース、フラットファイル、その他のコンポーネントなどにあるビジネスオブジェクトのアダプタパターンを使用して、古い形式または構造が不十分な形式をより適切なものに変換します。

そうは言っても、データベースの現在の構造よりもニーズに適したマナーでデータを表すために、ビューまたはストアドプロシージャを作成できます。これは、データベースへのアクセスが許可されていることを前提としています。

于 2009-09-01T02:07:41.727 に答える
2

データベースをダンプします。つまり、スキーマを再設計し、データを移行すれば、問題はないはずです。

于 2009-09-01T03:09:23.873 に答える