問題タブ [design-patterns]

私は過去に多くのプロジェクトで db4o を使用して多くの成功を収めてきました。時間が経つにつれて大きく進化したようで、LINQ のような現代のトレンドがみんなの口に出てきたことで、再び私の関心がピークに達しました。特に、透明なアクティベーションと永続性をサポートし始めていることがわかったので、かなり興味をそそられましたが、友人私が最初に db4o について言及したとき、私に非常に良い質問を投げかけました。そして、現代の技術革新をもってしても、私はまだそれに答える方法がわかりません.

SQL などのプラットフォームで非常に効果的に実行できる、大規模なクロステーブルの複雑な制約レポートに似たレポートを生成するための最良/最速/最も一般的な方法は何ですか? 時間、労力、および開発時間がどれだけ節約され、特に ORM を介して多くのパフォーマンスが向上するかはよく理解していますが、一部のアプリケーションでは複雑なレポートが必要であり、オブジェクトやオブジェクト クエリを使用して表現する方法がわかりません。複雑なレポートを最適化して維持することは、その目的のために特別に設計されたシステムであっても大変な作業になる可能性があるためです。

--
編集:

より明確にするために、オブジェクト データ ソースなどを使用して、db4o を SqlDataSource などと同じデータ豊富なコントロールに取り込むことができます。ReportViewer での使用に関する db4o サイトのドキュメントを参照したり、データを非正規化してレポート データベースにすることを勧められたりしましたが、この質問は、次のような種類のクエリを実行するために何ができるかについて、概念的な課題を提示することを意図しています。 RDBMS は非常に優れたパフォーマンスを発揮し、業界をリードしています。私は db4o が大好きですが、関連するすべてのオブジェクトをデータベースから取り出してアクティブ化し、計算を実行せずに、いくつかの異なるタイプ (または SQL のテーブル) にまたがって存在する集計データをレポートする真に効率的な方法を思いつきません。アプリケーションレベルのコードで。私は間違っているかもしれませんが、これはできなかったようです」

ここに集まることができた優秀な頭脳の中に、誰かが私が知らないことを知っているか、ODBMS の分野を拡大できる将来の実装のための革新的なアイデアを持っていることを願っています。私は、さまざまな ORM が複雑なレポート オブジェクトの方法論を実装していることを知っています。また、これらのテクノロジのいずれかの経験を持つ人が、私のコードと db4o 以外のテクノロジに依存しない創造的なものを持っているのではないかと考えています (私は、 SQL サーバーのみ)。

Python PubSubライブラリと同様の機能を提供するac＃ライブラリはありますか？イベントを使用する代わりに、特定のトピックのメッセージをサブスクライブできるオブザーバーパターンのようなものだと思います。

私は現在、多くのエンティティ（人、組織）と多くの連絡先情報を持つWebビジネスアプリケーションに取り組んでいます。複数の住所、メールアドレス、電話番号など

現時点では、データベース スキーマは、個人テーブルに郵便番号列、組織テーブルと同様に電話番号列があるようなものです。これは、これを処理する良い方法ではありません。

私はこれについて c2 Wiki を読みましたが、連絡先と住所のモデル ( http://c2.com/cgi-bin/wiki?ContactAndAddressModels ) と物理アドレスが古風であるかどうか ( http://c2 .com/cgi-bin/wiki?ArePhysicalPostalAddressesArchaic )。これらの 2 つの議論は、この問題の範囲について本当に私の目を開かせてくれました。

連絡先情報フィールドを分離してテーブルを分離することを考えています。しかし、これを行う最善の方法は何ですか。現時点では、このアプリケーションは主にフィンランドの住所を処理しますが、国際的な住所も処理する必要があると考えられています。

「住所」テーブル、「電話番号」テーブル、「電子メール アドレス」テーブルなどを定義でき、これらは人や組織にリンクされます。しかし、これは前のソリューションに似すぎているように感じます。定義済みのデータベース スキーマが十分でないことは避けられません。

私が提案しているのは、動的な連絡先情報スキーマ/プログラム ロジックを作成することです。

• 事前定義された連絡先情報フィールド/フィールド セットはありません
• ユーザーはいつでも新しい連絡先情報の種類と必須フィールドを定義できます。
  • フィンランドの住所
  • スウェーデンの住所
  • ... 住所
  • 電話番号
  • 電子メールアドレス
  • ICQ番号

これは実現可能ですか？誰かがこのようなことをしましたか？

連絡先情報の種類を定義するテーブルが存在する可能性があります。

連絡先情報の種類

• Id: 識別子
• 名前: 「フィンランドの住所」
• 説明: 「フィンランドの住所にはこの連絡先情報タイプを使用してください」

次に、連絡先情報の種類ごとに使用されるフィールドを定義するテーブルが存在する可能性があります。

連絡先情報タイプ フィールド

• Id: 識別子
• Contact_information_type_id: 前の表を参照
• フィールドのタイトル: 「住所 1」
• フィールドの説明: 「この行を郵便住所の最初の行に使用する」
• フィールド タイプ: 文字列/整数/など。
• フィールド形式: フィールド データを検証するための正規表現
• フィールドの順序: この連絡先情報の種類を表示/使用するときに、このフィールドが表示される順序

次に、連絡先情報フィールドを一緒にマップするために使用される「連絡先情報テーブル」を作成します。

連絡先

• Id: 識別子
• Contact_information_type_id: 連絡先情報種別テーブルを参照

次に、さまざまな連絡先情報を人にマッピングする「連絡先情報」テーブルを作成します。

本人連絡先

• Id: 識別子
• Contact_information_id: 連絡先情報テーブルを参照します
• 個人ID：個人を参照します

次に、次のような連絡先情報フィールド タイプごとのテーブルが必要になります。

連絡先情報整数フィールド

などの文字列など...

最後に、特定の人物のさまざまな連絡先情報を表示する場合、これはその人の連絡先情報テーブルを通じて発生します。この連絡先情報を形成するために使用されるフィールドは、連絡先情報タイプ フィールドテーブルから連絡先情報テーブルを通じて検索されます。使用するフィールドを決定したら、必要なすべてのテーブルを結合します。

SQLでの実現可能性について疑問があります。何かご意見は？

Java では、おそらく何らかのロジックをプログラムして、連絡先情報エンティティを形成するために必要なテーブルを決定し、何らかの動的 Bean を使用して Java でこのデータを表すことができます。しかし、それは私にとっても少し曇っています。これについても考えていますか？

異なるファイル形式を保存およびロードするときに使用するのに適したパターンはありますか?

たとえば、ドキュメントのクラス階層が複雑ですが、いくつかの異なるファイル形式をサポートしたいと考えています。

Strategy パターンについて考えましたが、オブジェクトを保存およびロードするためにオブジェクトのすべての部分にアクセスする必要があるため、納得できません。

デジタル信号取得システムでは、多くの場合、データは1つのスレッドによってシステム内のオブザーバーにプッシュされます。

Wikipedia / Observer_patternの例：

たとえば、GUIスレッドからのユーザーアクションでデータの流れを停止する必要がある場合は、サブジェクトとオブザーバーの接続を切断し、オブザーバーをまとめて破棄する必要があります。

議論の余地があるかもしれません。データソースを停止し、番兵の値が接続を破棄するのを待つ必要があります。ただし、システムの遅延が大きくなります。

もちろん、データポンピングスレッドがオブザーバーのアドレスを要求したばかりの場合は、破壊されたオブジェクトにメッセージを送信していることに気付く可能性があります。

誰かがこの状況に対抗する「公式の」デザインパターンを作成しましたか？彼らはすべきではありませんか？

GoF の本を読めば、デザイン パターンとは何か、そしてその使い方を学ぶことができますが、デザイン パターンが問題を解決するタイミングを理解するプロセスとはどのようなものでしょうか? パターンの知識はデザインを動かしますか、それともパターンを使ってデザインを変更する方法を理解する方法はありますか?

つまり、パターンにはパターンがありますか？

編集:別の質問から、シングルトンに関する多くの質問/回答へのリンクを含む回答を提供しました:シングルトンに関する詳細はこちら:

だから私はスレッドSingletons: good design or a crutch?を読みました。
そして議論は今も激しさを増しています。

私はシングルトンをデザイン パターン (良い面も悪い面も) と考えています。

Singleton の問題はパターンではなく、むしろユーザーにあります (申し訳ありません)。誰もが、そしてその父親は、正しく実装できると考えています (そして、私が行った多くのインタビューから、ほとんどの人は実装できません)。また、誰もが正しいシングルトンを実装できると考えているため、パターンを悪用し、不適切な状況で使用します (グローバル変数をシングルトンに置き換えます!)。

したがって、答える必要がある主な質問は次のとおりです。

• シングルトンを使用する必要がある場合
• シングルトンを正しく実装するにはどうすればよいですか

この記事に対する私の希望は、Singleton をいつ (そしてどのように) 正しく使用するかについての信頼できる情報源を (複数のサイトをグーグル検索して検索するのではなく) 1 か所にまとめることができることです。また、適切な使用法と一般的な悪い実装のリストは、それらが機能しない理由と、適切な実装の場合はその弱点を説明しています。

ボールを転がしてみましょう:
私は手を挙げて、これは私が使用しているものですが、おそらく問題があると言います.
「Scott Myers」の著書「Effective C++」での主題の扱いが好きです。

シングルトンを使用するのに適した状況 (多くはありません):

• ロギング フレームワーク
• スレッド リサイクル プール

わかった。いくつかの批判と他の実装をまとめてみましょう。
:-)

この質問で時間を無駄にしないでください。フォローアップ:シングルトンの何がそんなに悪いのか?

お気軽にSingletonでビッチしてください。

Singletonを不適切に使用すると、多くのペイントが発生する可能性があります。シングルトンでどのような問題が発生しましたか? このパターンの一般的な誤用は何ですか?

Corey の回答を掘り下げた後、このトピックに関するいくつかの素晴らしい記事を発見しました。

• シングルトンが物議を醸す理由
• 高性能シングルトン
• シングルトンは病的な嘘つき
• すべてのシングルトンはどこへ行った?
• シングルトンの根本原因

私は次のタイプを持っています:

このタイプをある種の専用コントローラー/ビルダーで作成および更新したいのですが、他のタイプに対しては読み取り専用のままにしておきたいです。

このオブジェクトは、コントローラー/ビルダーによって更新されるたびにイベントを発生させる必要もあります。

要約すると、前の型定義スケルトンによると:

• はPerson特定のコントローラによってのみインスタンス化できます
• このコントローラーは、 (フィールド)の状態をいつでも更新できます。Personname
• 発生時に世界中に通知Personを送信する必要性
• 他のすべてのタイプは、属性の読み取り のみ可能にする必要がありますPerson

これをどのように実装すればよいですか? ここではコントローラー/ビルダーについて話していますが、他のすべてのソリューションは大歓迎です。

注:修飾子に頼ることができますがinternal、理想的にはすべてのものを同じアセンブリにする必要があります。

トランザクション プログラミングは、今日の現代の開発では欠かせないものです。同時実行性とフォールト トレランスは、アプリケーションの寿命にとって重要であり、当然のことながら、トランザクション ロジックは実装が容易になりました。ただし、アプリケーションが成長するにつれて、トランザクション コードはアプリケーションのスケーラビリティに対してますます負担になる傾向があるようです。また、分散トランザクションとミラーリングされたデータ セットにブリッジすると、問題が非常に複雑になり始めます。データ サイズやアプリケーションの複雑さの点で、トランザクションが頻繁に問題の原因になり始めている点 (タイムアウト、デッドロック、ミッション クリティカルなコードでのパフォーマンスの問題など) は、修正やトラブルシューティングがより面倒であることに興味があります。または、それ自体がよりフォールト トレラントなデータ モデルを設計するよりも回避策を講じる必要があります。または他の手段を使用してデータの整合性を確保します。また、これらの影響を最小限に抑えたり、標準的なトランザクション ロジックを時代遅れにしたり、問題にならないようにしたりするのに役立つ設計パターンは何ですか?

--

編集：これまでのところ、妥当な品質の回答がいくつかありますが、追加の創造性を刺激しようとするために聞いたことのいくつかを取り上げるために、自分で回答を投稿すると思います。私が得ている回答のほとんどは、問題に対する悲観的な見方です。

もう 1 つの重要な注意点は、すべてのデッドロックが不十分なコード化された手順の結果であるとは限らないということです。場合によっては、異なる順序で類似のリソースに依存するミッション クリティカルな操作や、互いにステップする異なるクエリの複雑な結合があります。これは避けられない問題のように思えることもありますが、私はワークフローの再構築に参加して、この問題が発生する可能性が低い実行順序を容易にしています。