問題タブ [poco]

MyGeneration を nHibernate と共に使用して、基本的な POCO オブジェクトと XML マッピング ファイルを作成します。コード ジェネレーターは良い考えではないと考える人がいると聞いたことがあります。現在の最良の考え方は何ですか？何千行もの理解できないコードが生成されると、コード生成が悪いだけですか?

I have a POCO object that goes 4 levels deep contained objects (like Invoice has line items that have taxes that have gl entries), and I want to turn the entire thing into a DataSet. So there would be 4 tables, each with constraints being applied to the parent table.

Does anyone know of something that would automated this?

誰かが「POCO」の正確な意味を定義できますか？私はこの用語にますます頻繁に出くわします、そしてそれが単なるクラスに関するものなのか、それとももっと何かを意味するのか疑問に思います。

さて、モデルを LINQ を使用するように変換しようとしましたが、現在の DTO と、ドメイン全体に散らばっているインターフェイスを破棄したくありませんでした。

プロセスの概要を非常にうまくまとめたこのブログ投稿を見つけることができました。

LINQ To SQL で POCO を達成する

オブジェクトへのレコードの取得は正常に機能していますが、モデルのネストされた性質により、子オブジェクトの追加機能を取得できないようです。つまり、子オブジェクトを作成し、目的の親オブジェクトへの参照を設定すると、LINQ to SQL は、親への子の参照が null であることを示す例外をスローします。単純な古い親オブジェクトを追加しようとすると成功しますが、子オブジェクトを直接追加すると失敗します

これが私の失敗したテストです：

エラーメッセージは次のとおりです。

System.InvalidOperationException: Market と Selection の間の関係を削除しようとしました。ただし、リレーションシップの外部キー (Selection.MID) の 1 つを null に設定することはできません。

2 つのオブジェクトの関連部分:

私のDAコード:

と;

そして最後に私の XML マッピング:

それで、誰かが私を正しい方向に向けることができますか？私は何時間も探していました...

編集：

テスト失敗のスタックトレースは次のとおりです。

そして私の GetMarket メソッド:

編集2：

さて、追加

XML マッピングの外部キーを選択すると、外部キー エラーが削除されましたが、現在、選択の子オブジェクトの 1 つで null 参照を取得しています。選択が変数セットなしで初期化されているにもかかわらず、選択への参照が null であると言っています。 （外部キーの外）。私は子オブジェクトを作成しようとしましたが、その参照を正しく設定しましたが、まだこのエラーが発生しています:

価格は別のオブジェクトであり、その選択が市場に関連するのと同じように構築されます (1 つの選択には多くの価格があり、1 つの市場には多くの選択があります) など。

違いは何ですか

• 単純なフィールド アクセサー ミューテータークラス
• 豊富なモデル化されたクラス

ビジネス ドメイン クラスのリッチ モデリングを構成する要素は何ですか?

話題にある通り…

「記憶の変化」のようなものを考えていました。Jaroslaw Kowalski による最近のブログで、同様のアプローチを見つけましたが、sth についてはもっと単純に考えていました。

私は ASP.NET MVC や SOLID などについていくつか読んできましたが、これらの概念をまとめた小規模から中規模の ASP.NET MVC アプリの簡単な "レシピ" を見つけようとしています。私が最も懸念している問題は、コントローラーが複雑すぎて、Web フォームのコード ビハインド ファイルのようになり、あらゆる種類のビジネス ロジックが組み込まれることです。

小さなデータ駆動型アプリの場合、次のアーキテクチャを検討しています。

• コントローラー: リクエストのみを処理し、適切なサービスを呼び出して、アクションの結果をビューに返します。
• モデル: POCO、すべてのビジネス ロジック、承認などを処理します。リポジトリに依存し、永続化インフラストラクチャをまったく知りません。
• リポジトリ: 実装しIRepository<T>、依存性注入を使用し、私のデータベース コードが存在する場所です。POCOを受け取り、返すだけです。

コントローラーとモデルの間にサービスを配置することを検討していますが、メソッド呼び出しを転送するだけの場合、それがどれほど役立つかわかりません。

最後に、モデル コードをカバーする単体テストと、リポジトリ コードをカバーする単体テストと統合テストが必要です (可能であれば、「レッド グリーン」プラクティスに従います)。

考え？

私のチームは EFPocoAdapter を使用したいと考えていますが、DynamicData ツールも使用したいと考えていますが、いくつか問題があります。

基本的に、「Dynamic Data Entities Web Application」プロジェクトを EFPocoAdapter Northwind サンプル ソリューションに追加し (私は最新バージョンの 1.03 を使用しています)、必要なアセンブリを参照してから、登録する Global.asax.cs ファイルの行のコメントを外して編集しました。 MetaModel を使用したコンテキストは次のようになります。

次のエラーが表示されます:「コンテキスト タイプ 'NorthwindEF.NorthwindEntities' はサポートされていません。」

私たちが抱えている問題は、どうすればこれを有効なコンテキストにすることができるか、またはこれを機能させるために何かをハッキングするにはどうすればよいかということです。

ご指摘ありがとうございます。

考えすぎた結果、Linq To SQL をプロジェクトの DAL として使用することにしましたが、ビジネス オブジェクトは POCO オブジェクトのままにしておきます。

データベーススキーマは古く、下位互換性のために解決できない問題があるため、これによりある程度の柔軟性が得られます。

リフレクションを使用して、LINQ オブジェクトを POCO オブジェクトに取得または完了するメソッドを作成することを考えています。このメソッドは、すべてのプロパティを同じ名前で埋めようとする必要があります。

質問:
マッピングを行うためのより良い方法を知っていますか?

明確化:
1. NHibernate や Entities などは使いたくない
2. リフレクションが遅いことはわかっている