問題タブ [poco]

私は別のSOスレッドからのこの回答に興味を持っており、誰かが私にコンセプトに光を当てるのを手伝ってくれることを望んでいました。

プライマリAppDomainと、プライマリAppDomainによって作成および初期化される子AppDomainの束があるとします。擬似コードの場合：

プライマリAppDomain：

子AppDomain：

Init（）中に、子AppDomainはPOCOオブジェクトをインスタンス化します。これは、定義上、マーシャリングできません。また、その点で変更できないと仮定しましょう。

リンクされた回答は、それをContainer<T>（それ自体がマーシャリング可能である）でラップすると、プライマリAppDomainに戻すことができるようにする必要があることを示唆しています。Container<MyInfo>実際に渡されるのはインスタンスへのプロキシであるため、これを理解しています。

私が理解していないのは、プライマリAppDomainがコンテナのプロキシを介してコンテナ内のPOCOインスタンスにアクセスする方法です。オーバーロードされた暗黙のキャスト演算子が表示されContainer<T>、含まれているPOCOインスタンスが返されることを理解しています。しかし、そのインスタンスはそれ自体がプロキシされていません-それはまだ子AppDomainにあります！だから、これは壊れるべきではありませんか？

ここで実際に何が起こっているのですか？

FTPを介して対話する必要があるアプリケーションを開発しています。この通信には、現在WindowsでC ++、Visual Studio、Pocoを使用しています。

次の行では、bad_alloc例外が発生します。

だから私はダウンして最初にStreamSocketを初期化しようとしましたが、失敗します...

さらに下に行くと、bad_allocは次の場所から来ているようです。

そのコンストラクターには次のものが含まれます:(デバッガーで_pImplが初期化されていないことがわかります）

IPv4AddressImpl :: parseに含まれるもの：

Winsock2.h（ws2_32.lib）のinet_addrを含む次のコードは、「SOMETHINGELSE」になります。

ここで何が問題になっているのかわかりません...これをさらにデバッグする方法はありますか、それとも誰かが何が問題になっているのか知っていますか？

多くの場合、ドメイン オブジェクトをさまざまな方法で UI に表示する必要があります。リスト、検索結果、ページの表示と編集、ヘッダー、フッター、ポップアップ。通常、ドメイン オブジェクトのいくつかの異なる「ビュー」があり、それぞれに異なるフィールドが表示されます。

サブセットまたはスーパーセットが必要な場合は、DTO を使用してデータを取得することをお勧めします。DTO の維持には多くのオーバーヘッドがあります。各シナリオに必要なドメイン オブジェクトのプロパティを単純に入力するのは悪い方法ですか。たとえば、プロファイルを使用して、含める必要があるプロパティを指定できます。たとえば、次のようになります。

service.GetDomainObjects(int listID, Profile.ListProfile); service.GetDomainObjects(string searchParam, Profile.SearchProfile);

POCO と DTO の違いを調べていたところ(POCO は動作 (メソッド?) を伴う dto のようです) 、貧血ドメイン モデルに関する Martin Fowler の記事に出会いました。

理解の欠如により、私はこれらの貧血ドメイン モデルの 1 つを作成したと思います。

私のアプリケーションの 1 つで、'dto' dll でビジネス ドメイン エンティティを定義しています。それらには、ゲッターとセッターを備えた多くのプロパティがあり、他にはあまりありません。ビジネス ロジック コード (入力、計算) は別の 'bll' dll にあり、データ アクセス コードは 'dal' dll にあります。「ベストプラクティス」と思いました。

したがって、通常、次のように dto を作成します。

次のように bll レイヤーに渡します。

次に、いくつかのロジックを実行し、次のように dal レイヤーに渡します。

私の理解では、dto を POCO にするには、ビジネス ロジックと動作 (メソッド) をオブジェクトの一部にする必要があります。したがって、上記のコードの代わりに、次のようになります。

すなわち。オブジェクトをメソッドに渡すのではなく、オブジェクトのメソッドを呼び出しています。

私の質問は、どうすればこれを行うことができ、「ベストプラクティス」の懸念事項の階層化 (個別の dll など...) を保持することができるかということです。オブジェクトでメソッドを呼び出すということは、オブジェクトでメソッドを定義する必要があるということではありませんか?

私の混乱を助けてください。

Entity Framework の永続性を無視しないことについて読んでいると、よくPOCO Adapterに出くわします。問題は、それを本番環境で使用する人がいるか、どのように動作し、落とし穴は何かということです。

アプリケーション設計には 2 つの選択肢を検討します。ビジネス ロジックでそのアダプターを使用して POCO を使用し、プレゼンテーション レイヤーでそれらを使用するか、EF エンティティと DTO の間で変換するサービス レイヤーを作成します。(1) EF エンティティ <-> アダプター <-> POCO ビジネスオブジェクト <-> プレゼンテーションまたは (2) EF エンティティ <-> サービス層 <-> DTO <-> プレゼンテーション。最初のアプローチはよりクリーンに見えますが、POCO アダプターがあまり標準的なソリューションではなく、現時点では明らかでないいくつかの欠点が含まれている可能性があることについて、私は少し躊躇しています。

POCOに関する記事をたくさん見てきました。これは何ですか？

単体テストで POCO をカバーしたいと考えています。

それらをどのようにテストすればよいですか？

新しいプロパティを追加するとどうなりますか? テストを失敗させるにはどうすればよいですか?

私が知っているプロパティとメソッドをテストしていますが、問題は、テストが失敗することを確認する方法が、poco に何かが追加されていることです。

私のチームでは、エンティティ データの更新とその最適なアプローチ方法について議論しています。これはセキュリティ フレームワークであるため、いくつかの制約とアイデアを次に示します。

1. DB のすべてのテーブルには、GUID である PK があります。これは、マルチノード クラスタリング ソリューションに必要です。アイデアは、API を介してエンティティでこれを顧客に公開したくないということです。
   1. 彼らの仕事に必要な情報を提供し、システムに関する情報をハッカーに提供します。
   2. サポートの悪夢は、クライアントが何らかの方法でこの ID にハードコードし、PK のクライアントを変更する必要がある場合に影響を受けることです。

解決策は、一意の Name を持つ Role オブジェクトや Realm などのアイテムの自然キーを公開することです。一意性を保証しますが、これらの値のいずれかを更新することは困難です。更新する古い値と新しい値を指定するか、2 つを渡す必要があるためです。元のオブジェクトと新しいオブジェクトのオブジェクト。更新するオブジェクトを見つけることができます。ややこしい、

別のアプローチは、代替キーを作成し、これをクライアントに公開して、クライアントが必要なだけ使用できるようにすることです。これは、PK に関連付けられていないため、気にしません。

最近では誰もがエンティティの ID として PK を問題なく使用しているように見えますが、昔のプログラミングの時代からベテランのチームを説得する方法がわかりません。

もう 1 つの問題は、部分的な更新をサポートする方法です。問題は、10 個のプロパティ、4 つのコレクションなどを持つエンティティがあり、名前 + レルムのコンボを使用して、オブジェクト全体をプルダウンする代わりに更新するプロパティを指定し、1 フィールドを変更して送り返すことです。アップデート用。コレクションを遅延ロードすると言いますが、部分的な更新が意味があるかどうかはわかりません。

考え？

ありがとう！

Projects、Users、ProjectMembersの3つのテーブルがあります。ProjectMembersテーブルはマッピングテーブルであり、ProjectIdとUserIdの2つの列しかありません。

私のオブジェクトモデルには、ProjectとUserの2つのクラスがあります。ProjectクラスにはプロパティがありますIEnumerable<User> Members

linqをsqlアソシエーションにマッピングするために外部xmlマップファイルを使用しています。プロジェクトとユーザーデータを取得できますが、メンバーの関連付けをマップする方法がわかりません。

3つの層（名前空間を含む）があるとします。

• ユーザーインターフェイス（App.UI）-ビジネスレイヤープロセスを呼び出し、オブジェクトを使用して通信します
• ビジネスレイヤー（App.Core）-プロセスを調整し、オブジェクトを使用してDALレイヤーを使用します
• DAL（App.Data）-ストアを直接操作し、オブジェクトを永続化します

Userテーブルがあり、DALレイヤーに反映されているとしましょApp.Data.UserうApp.Data.Users。

UIには、アプリケーションユーザーを表示するビューがあります。

分離された（階層化された）アプリケーションを実際に作成するには、アプリケーションも用意する必要がApp.Core.UserありApp.Core.Users、おそらく手動で作成する必要があります。

もちろん、（私の意見では）最善の解決策は次のようになります。クラスと。を含む第4層のBusiness Objects（App.Objects）が必要です。これらのPOCOは、すべてのレイヤーで共有されます。ビジネスレイヤーはDALの使用のみが許可され、UIはBLの使用のみが許可されますが、それらはすべて共通のオブジェクトモデルに使用されます。App.Objects.UserApp.Objects.UsersApp.Objects

Asp.net MVCテンプレートは、ビューで直接DALオブジェクトを使用することを意味します。LINQ2エンティティは、POCO自体も作成しません...

では、自動コード生成を使用する場合、DALオブジェクトを使用するのか、それとも共有POCOを手動でハードコーディングするのでしょうか。最初の部分は簡単な方法のように見えますが、 DALをUIから分離していません（後でセキュリティとスケーラビリティの問題が発生する可能性があります）。2番目の部分はエラーが発生しやすく、中規模のデータベースでは非常に面倒です。

あなたは何を提案しますか？