問題タブ [self-reference]

より経験豊富な開発者のアドバイスに従って、私は常に、ユーザー入力 (フォーム処理、データベース管理など) を必要とする Web ページを自己参照ページとしてコーディングしてきました。PHP ページの場合、フォームのアクションを定義済み変数の'PHP_SELF'要素に設定し$_SERVER、渡す引数に応じて、ページ ロジックが実行するコード ブロックを決定します。

すべてのコードが 1 つのファイルに含まれていて、さまざまな結果ページに分散していない点が気に入っています。私が見つけた 1 つの問題は、統計解析プログラムが、ページの最初のビューとその後のビュー (たとえば、フォームが送信されたとき) を区別できないことです。昔、CGI や CF を使ってページを作成したとき、フォームが実際に使用された回数が非常にきれいに表示される別の結果ページにユーザーを誘導しました。

Web 開発におけるこれらのタイプのページのベスト プラクティスは何ですか? 自己参照ページを使用する (または使用しない) 他に説得力のある理由はありますか?

関数を定義すると:

次のように、後でオブジェクトを関数の属性として保存できます。

関数自体のコード内からこれを行いたいと思います。問題は、関数自体から関数への参照を取得するにはどうすればよいですか?

委任されたタスクを別の関数で分離する代わりにインライン化する方法はありますか?

元のコード:

このようにしたかったのです（別の関数を作成する必要はありません）：

INSERTの前にレコードの一意性をチェックする場合の違いをよりよく理解したいと思います。CHECKSUM （一意の制約あり）を使用する場合と、以下のような自己参照テーブルステートメントを使用する場合の違いです。どのシナリオが、一方のオプションが他方よりも最良の選択となるのでしょうか。また、その理由は何ですか。

要件：列の各セットは、テーブル内のすべてのレコードから一意である必要があります。そのため、このステートメントをまとめました。データベースへの1回の呼び出しですべての列をチェックします。

Linq から SQL への関連する質問が 2 つあります。私のモデルがどのように見えるかを確認するには、下の画像を参照してください。

質問1

クラス/テーブルUser.AddedByUserにフィールドを熱心にロードする方法を理解しようとしています。Userこのフィールドは、User.AddedByUserIdフィールドの関係から生成されます。テーブルは自己参照型であり、Linq to SQL でUser.AddedByUserプロパティを熱心にロードする方法を見つけようとしています。つまり、Userエンティティがロード/フェッチされるたびに、User.AddedByUser と User.ChangedByUser もフェッチする必要があります。ただし、これが再帰的な問題になる可能性があることは理解しています...

アップデート 1.1:

次のように DataLoadOptions を使用しようとしました。

しかし、これは機能しません.2行目で次の例外が発生します:

例外は一目瞭然です。オブジェクト グラフは Cyclic であってはなりません。また、行 2 が例外をスローしなかったと仮定すると、重複キーであるため、行 3 は例外をスローしたと確信しています。

更新 1.2 :

以下も機能しません (上記のUpdate 1.1と組み合わせて使用​​されていません):

次の自明の例外がスローされます。

私は今、これを解決する方法について本当に途方に暮れています。助けてください！

質問2

Entity.ChangedByUser私のDBの他のすべてのテーブル、したがってLinq to SQLモデルには、 （外部キー/関係にリンクされたEntity.ChangedByUserId）およびEntity.AddedByUser（Entity.AddedByUserId外部キー/関係にリンクされた） 2つのフィールドがあります

Linq to SQL でこれらのフィールドを熱心にロードするにはどうすればよいですか? クエリで単純な結合を行う必要がありますか? または他の方法がありますか?

自己参照テーブルでの Linq to SQL の熱心な読み込み http://img245.imageshack.us/img245/5631/linqtosql.jpg

以下に定義されているサイト テーブルの複合主キーがあります。機能的には、これは私たちが望んでいるものとまったく同じです。各サイトには、同じ地区の親サイトが必要です。このようにテーブルを定義すると、特にそれが可能になります。

私の具体的な質問は、複合 PK で定義された自己参照 FK に関するものです。この特定のデザインについていくつかの意見を聞いたことがありますが、それらは相反する傾向があります。複合キーの一般的な理解の範囲内で機能するため、特に気に入っている人もいます。他の人は、それは理論的に正しくなく、[district_id] の代わりに [partner_district_id] フィールドを FK に含める必要があると主張しています。この設計では、[district_id] = [partner_district_id] を適用するための検証が必要になります。これは、チェック制約またはアプリケーション レベルのロジックで行うことができます。

これらのソリューションまたはその他のソリューションに関するさらなる意見をお待ちしております。

インターフェイスビルダーで以下を機能させる方法を理解するのに苦労しています。

いくつかの属性 (名、姓など) と他の人 (友人) との関係を持つ Core Data モデル クラス "Person" を作成しました。

概念的には、これは非常に単純です。ただし、これを IB で機能させる方法を理解するのは難しいことがわかっています。

ウィンドウの左側にすべての人を一覧表示するテーブルがあるインターフェイスを作成しました。右側には、人物の詳細を入力するためのフィールドがあります。

右側に「友達」と追加および削除ボタンを表示する小さなテーブルが必要です。追加ボタンをクリックすると、リストをフィルタリングするための検索機能を備えた小さなパネルが起動し、「友達」セットに追加する人を 1 人選択できます。

誰かが私にいくつかの提案をしたり、このようなことをすることがわかる例を教えてもらえますか?

前もってありがとう、マット

最近、C# でのジェネリック クラスの参照に関連する多くのコードの匂いがします。私の不満は、DependencyObject を継承し、DependencyProperties を含むクラスに特に当てはまります。

基本的な問題は、依存関係プロパティを宣言するときに、通常、所有者としても知られる現在の型を参照することです。これは問題なく機能し、一般に単純な非ジェネリック オブジェクトの場合はそれほど問題にはなりませんが、オブジェクトにいくつかの依存関係プロパティが含まれており、型名をさまざまな場所でリファクタリングする必要がある場合を除きます (ビジュアル スタジオ)。

私が最近見つけたのは、この面倒な明示的な自己参照の慣行とジェネリックの広範な使用を組み合わせると、コードが本当に醜くなり始めるということです。

私の質問は、上記のような状況でジェネリック パラメーターを含む完全な型名を参照する必要がある回数を減らすためのトリック、ハック、または正当な解決策を誰かが知っているかどうかです。

完全な開示: 私はこれを Microsoft .Connect サイトの問題として提起しましたが、自己参照キーワードのアイデアを拒否しましたが、回避策や代替ソリューションは提供しませんでした. 私の考えは、キーワードが使用されている型を一般的に参照するために、 Owner、OwnerClass、またはThisTypeなどのキーワードを使用することでした。

次の要件を実装するには、C# でどのタイプのコレクションが最適だと思いますか?

1. Web ファイル (例: class = "webfile") をモデル化する必要があるため、1 つのクラスのみが優先されます
2. 親と子の関係のモデル化 - 関連付けに関しては、Web ファイルは複数の子 Web ファイルを持つことができ、子 Web ファイルは複数の親を持つことができます。(複数の画像を含む HTML ページ、または同じ画像を共有する複数の HTML ページを考えてください)
3. ファイルは親と子の両方になることができます。つまり、HTML ページは他の HTML ページへのリンクを持つことができます。
4. どこにも重複があってはなりません。URI がキーであると想定してください。ある意味では、Web サイトに置かれているファイルをモデル化したいと考えています。画像 XYZ の実際のコピーは 1 つだけですが、複数のページからのリンクがあります。
5. 実際の webfile クラス自体は一意の URI をキーにしていますが、lastmodifieddate、size などのクラス内の他の属性を想定しています。
6. ああ、データを保存/ロードするために、クラスでも XML シリアライゼーションを使用するつもりでした。これが答えに影響するかどうかわからない

どのコレクションがベストだと思いますか? (実装するコード自体は素晴らしいものですが、基本的な方向性だけで十分です)。リストの使用を開始しましたが、「addChild(parent, child)」などのパブリック メソッドを実装しようとすると、既存の Web ファイル (つまり URI) の存在を確認するコードを記述しなければならないことがわかりました。そのため、おそらくキーの 1 つを使用する私にとって一意性が保証されるのであれば、コレクションクラスがここで最適でしょうか?

これが理にかなっていることを願っています。

Tks