問題タブ [circular-reference]

MyRepository別のDALプロジェクトにある以下のようなシングルトンクラスを作成しようとしています。メソッドがクラスをGetMySingleTon()返し、そのアクセスを必要とするため、循環参照の問題が発生しています。MySingleTon同じように、クラスMyRepositoryのコンストラクターでアクセスする必要があります。MySingleTon

更新：私はそれを非常に間違ってやっていた。シングルトンは必要なかったと思います。これで、3番目のプロジェクトで静的プロパティを持つクラスを作成し、一度設定してどこからでもアクセスできるようになりました。そして、それは今のところ私の問題を解決しました。

皆様のご回答ありがとうございます。

私の .net ソリューションには 3 つのプロジェクトがあります。
メイン プロジェクトと 2 つのクラス ライブラリ プロジェクト。

クラス ライブラリ プロジェクトを相互参照する必要があることがわかりました。
それをしてもいいですか？それは安全ですか、それともいくつかの考慮事項がありますか？

私はEF4が初めてで、できる限りガイダンスに従おうとしているので、POCOルートをたどることを選択し、POCOクラスを独自のプロジェクトに配置しました。DataAccess プロジェクトにリポジトリ クラスを追加しました。もちろん、DataAccess プロジェクトは POCO プロジェクトを参照します。

私は現在、POCO クラスにビジネス機能を追加していますが、POCO オブジェクトの 1 つの特定のメソッドが他の POCO オブジェクトの束を作成するという障害に遭遇しました。これは素晴らしいことです。しかし、それが作成するPOCOオブジェクトはすでにデータベースにあるので、もちろん循環参照を作成しているDataAccessプロジェクトを参照するにはBusinessEntityプロジェクトが必要であることを知っています。

このスペースでのガイダンスは大歓迎です。

私はこれに1日と少しの間、パン屋を所有する友人のために開発しているアプリのデータベース（MySQL）を最適にモデル化する方法を見つけようとしています。前提条件は次のとおりです。

• 多くの（外部）Bakersが多くを生み出すProducts
• BakersProductsは、製品の価格についてパン屋に電話するか、パン屋が価格表をファックスで送信する特定のスタッフによって隔週で更新されます。その後、スタッフはフロントエンドUIを介して更新します。
• マネージャーは、自分が持っていると予想する製品に基づいて注文を生成できる必要があります。

したがって、フロントエンドUIは、マネージャーが注文で希望する商品を純粋に選択できるようにし、注文の各商品について選択できるパン屋のリストをマネージャーに提示できる必要があります。

つまり、Orders_has_Productsへの参照も含める必要がありますBakersProducts.bpID。これを行うと、（ある種の）循環参照を作成することになると確信していますProducts。

私はこれを間違った方法で行ったと確信しており、選択した製品価格に対応するためにデザインを再構築する方法について、誰かのアドバイスを本当にいただければ幸いです。含めるBakersProducts.bpID。

ありがとうございました！

データ モデルから POCO オブジェクトを抽出しました。循環参照があります (つまり、Customer には連絡先があり、Contacts には Customer があります)。一方向の参照が必要です。つまり、Customer に連絡先があります。Contacts の参照を削除するにはどうすればよいですか?お客様へ。

各オブジェクトに移動して参照を削除するか、非公開にすることはできますが、モデルを更新するたびに参照も更新する必要があるため、それは柔軟ではありません。簡単な方法はありますか？

私は C++ プログラミングが初めてなので、私の質問がばかげていると思うかもしれません。申し訳ありませんが、この Java スタイルの構造を実装する方法を知りたいです。

コンパイラは、このコードを理解しようとして夢中になっています。可能な解決策について教えてください。ありがとう！

私は誤って次のような状況に遭遇しました (例は問題を特定するために単純化されています)。

誰もが出力を推測したいですか? :-)

出力は一種の理にかなっています。どうやら Second オブジェクトが作成された時点では、First オブジェクトがまだ存在しないため、null割り当てられます。問題は... それはとても間違っている ！これを追跡するのに数時間かかりました。コンパイラはこれについて何かを伝えるべきではありませんか? 興味深いことに、これを Scala スクリプト (同じコード、マイナスobject Mainとdef main行、および終了}s) として実行しようとすると、無限のシーケンスが得られました (実際には無限ではありません - ある時点でリストが停止します。何らかの制限が原因だと思います)。例外トレースの深さ、または何か) で、次のような例外の:

実行時に少なくとも同じくらい有益なものを取得したいと思います...

Ok。私は私の暴言を終えました。今、私は何かを尋ねるべきだと思います。:) では、お互いを指しているケースオブジェクトの素敵なデザインをお勧めできますか? ちなみに、私の実際の状況では、次のインスタンスと前のインスタンスを循環的に指すオブジェクトがいくつかあります (最後のインスタンスは最初のインスタンスを指し、その逆も同様です)。

Scala 2.8.1-final の使用

編集: 私は私の主な問題の解決策を見つけました:

これはコンパイルされたバージョンで動作するようです (ただし、Scala スクリプトとしては動作しません!)。ここで何が起こっているのか、誰かに光を当てることができますか?

EDIT2：これはスクリプトとして機能します（sを使用するだけで同じことですdef）：

したがって、私のエンティティクラス（C＃で記述）は、すべての子オブジェクトがその親の参照を保持するParentプロパティを持っている必要がある親子モデルに従います。

このParentプロパティは、循環参照が原因でオブジェクトのシリアル化で問題を引き起こします。

親への参照を削除することも、XmlIgnoreとしてマークすることもできません（XMLを逆シリアル化するときに読み戻す必要があるため）

これについて何かアイデアはありますか？

次のように動作する Adob​​e AIR アプリを作成しました。

ユーザーがログインすると、setTimeout を使用して永久ループが作成されます。このループは HTTP リクエストを実行し、返された json md5 文字列をグローバル変数と比較します。これら 2 つの値が異なる場合、dom は新しいコンテンツで更新されます。ユーザーが返信の送信やメッセージの削除などの別のアクションを実行すると、サイレント更新が実行され、これによりループが「一時停止」します。基本的には、単純な電子メール クライアントのようなものです。

私がやっている方法は信頼性が低く、メモリリークを引き起こします。私はそれをゼロから書き直すつもりであり、私が今いるのと同じボートに行き着きたくありません. 誰かがそれを行う方法の例を教えてくれたり、アドバイスをくれたりしたら、大歓迎です. 前もって感謝します！

ツリー構造を表す ID と ParentID を持つデータベースに隣接リストがあります。

もちろん、レコードでは ParentID が ID と同じであってはなりませんが、無限ループを防ぐために循環参照も防止する必要があります。これらの循環参照は、理論的には 2 つ以上のレコードを含む可能性があります。( a->b、b->c、c->a など)

レコードごとに、パスを次のような文字列列に保存します。

私の質問は次のとおりです。挿入/更新するときに、循環参照が発生するかどうかを確認する方法はありますか?

ネストされたセットモデルなどについてすべて知っていることを付け加えておく必要があります。保存されたパスを使用した隣接方法を選択したのは、はるかに直感的だからです。トリガーと別のパステーブルで動作するようになりました。循環参照の可能性を除いて、魅力的に動作します。