3

レガシー アプリケーション用に最初に作成された既存のデータベースを使用するプロジェクトがあります。それは正常に動作しますが、時間の経過とともにかなりの数のテーブル/フィールドが失われたり、十分に活用されていませんが、履歴データはいつか役立つ可能性があるため、どこにも行きません.

2012 年 ('13) に入り、POCO 生成機能が組み込まれた ORM である Entity Framework 5 が登場しました (Nice Add!)。バン.. Oracle データベースへの接続を取得します。コンテキストといくつかの POCO をアップします。しかし、待ってください..私のPOCOは、私が対処したいPOCOではありません...もう必要のないフィールドがたくさんあります（絶対に必要ないと言っているわけではありませんが、確かなことはわかりません）、だから今、基本的に肥大化したテーブルマッパーであるこれらのPOCOを手に入れました...それで、どうすればいいですか。

ここにいくつかの解決策があります..

1)。それらを放り投げて、必要なフィールドのみを使用できます。

2)。モデル サーフェスに入り、使用されていないフィールドの削除を開始できます。

3)。「Code-First」アプローチを採用し、オブジェクトを既存の DB に結び付けます。ただし、これは大規模な DB です (これが可能であると確信していますよね?)

4)。独自のモデル プロジェクトで独自の POCO / DTO を作成すると、これらは基本的に「ドメイン モデル」になりますが、コンテキストへのマッピングが面倒になる可能性があります。

最後に、これらの POCO / DTO は独自のプロジェクトに含める必要がありますか?? 本当に得られるものは何か..「YAGNI」のようなものを見ると、.edmx のすぐ下に座って誰にも迷惑をかけないように感じます..

余談ですが、JSON 経由でもこれらのいくつかが必要になるため、シリアル化可能な機能全体を考慮する必要があります..

生成された POCO を部分的に分類し、必要なプロパティのみを「属性」にすることはできますか?

とにかく、過去の経験から、または問題についての考えを聞くのは素晴らしいことです..

これはProgrammersにあることがわかりましたが、ここから始めることにしました。

4

1 に答える 1

1

非常によく似た状況があり、アプリケーション用に特定のテーブルの小さな部分が必要な大規模なレガシー DB2 データベースがあります。

これを行うために、関心のあるデータの関連するサブセクションにエンティティ フレームワーク コード ファースト モデルを使用しました。これは、いくつかの重要なことを実行できることを意味しました。

  • モデルから無関係なデータを削除して、コードを見つけやすくする
  • モデル内のフィールドの名前を変更し、既存の列名ではなく、アプリで意味のある名前にマップします
  • クエリによって引き戻されるデータの量を減らします (つまり、select はすべての余分なビットを取得しません)。
  • 2 つの形式のデータが存在する場合は、過去の形式ではなく最新の標準を使用します

これは私たちにとって非常にうまく機能しますが、注意すべき点がいくつかあります。

  • 書いている場合は、モデルにすべての必須フィールドが含まれていることを確認してください
  • CFクラスを生成できますが、少しトリミングする必要があります
  • 非 mssql からの生成は、よりトリッキーになる場合があります

json シリアライゼーションに関してもこれを行いますが、これには別のモデルを使用し、automapper を使用して変換します。ほとんどの場合、追加の属性を追加する必要なくシリアル化できるはずですが、必要な場合は、ef 属性と一緒に pocos に追加するだけです。

于 2013-01-10T22:44:47.817 に答える