問題タブ [decoupling]

これは C# の質問ですが、実際には言語に依存しない可能性があります

私は大規模なオブジェクト モデル (100 以上の型) を継承しました。オブジェクトの階層は、0..n の他の型指定されたオブジェクトをすべて「所有」し、すべてがベースを共有します (「相対的に」厳密な型階層がある場合)。

継承によってこれらのオブジェクトの分離を開始し、IoC ベースのシステムをまとめて、現在存在するよりも深いユニット テストの実装を開始したいと考えています。

どこから始めるのが最適ですか?

階層の最上位から始めることができます。これは非常に単純ですが、最初のメリットが最も少なく、チェーンのさらに下に到達するまでは非常に単純です。完全なカバレッジが得られるまで、関数シグネチャをオーバーロードして基本インターフェイスを受け入れます。

階層の一番下から始めることもできますが、それははるかにトリッキーです。なぜなら、そこにはクラス間の相互作用がたくさんあるからです。

ベース オブジェクト (すべてのオブジェクトが継承するオブジェクト) から開始することもできます。これにより、論理的なポイントでプロセスが開始されますが、すべてのオブジェクトの継承と関数呼び出しを交換するまで、ほぼ確実にコンパイルできないアプリケーションが作成されます。 .

何かご意見は？

私はJuvalLowyの優れたプログラミングWCFサービスを研究しており、ServiceModelExライブラリに付属するInProcFactoryクラスを使用して、非常に単純なin-procコンポーネントを作成しました。

プロジェクトで通常のクラスだけを使用する代わりに、なぜこれを行うのですか？彼のメソッドを使用するには、彼のライブラリを参照してインターフェイスを作成する必要があります。

私はいくつかの利点を考えることができます：

• これを一貫して行うと、結合が大幅に減少します。
• インプロセスコンポーネントを作成すると、変更せずにアウトプロセスまたはリモートで使用できるようになります。

これを行うことでより多くの利点がありますか？

インプロセスWCFコンポーネントを使用してコードを記述していますか？

すべてのクラスをコンポーネントにする必要がありますか？

デカップリング全体で完全に船外に出ることができますか？

すべてのクラスをコンポーネント化することの欠点は、利点を上回りますか？逆に？

一部の「リスクの高い」データ操作をログに記録する必要があります。この場合、「高リスク」操作は、ERPシステムへの書き込みとして定義されます。これらのイベントをSQLServerデータベースに記録していることがあります。

擬似コード：

この密結合を排除するためのベストプラクティスは何ですか？

作成中のアプリケーションで SubSonic (2.2) を使用したいと考えています。その単純さが好きで、必要と予測できるあらゆるタイプのクエリを処理できるからです。同時に、アプリケーションの上位レイヤーを亜音速タイプから切り離したいと考えています。Plain Old C# オブジェクトだけを返し、POCO を渡して保存したいと考えています。

しかし、ここに問題があります。POCO に、FK 関係に基づいて、子コレクションと親オブジェクトの遅延読み込みプロパティを持たせたいのです。Subsonic SqlQuery オブジェクトを POCO のプライベート メンバーに何らかの形で配置し、遅延ロードされたプロパティのゲッターで内部的に使用する必要があると考えています。

具体的に SubSonic でこれを実装する方法についてのアイデアはありますか? 誰もこれを以前にやったことがありますか？

SubSonic の次のメジャー リリースでこれがすぐに使えるようになることはわかっていますが、それは少なくとも数か月先のようです。

アプリケーションの設計に適合する設計パターンを探しています。

私のアプリケーションは大量のデータを処理し、いくつかのグラフを生成します。データ処理 (ファイルからのフェッチ、CPU を集中的に使用する計算) とグラフ操作 (描画、更新) は、別のスレッドで実行されます。

グラフはスクロールできます。この場合、新しいデータ部分を処理する必要があります。グラフには複数の系列が存在する可能性があるため、複数のスレッドを生成できます (系列ごとに 2 つのスレッド、データセットの更新用に 1 つ、グラフの更新用に 1 つ)。

複数の進行状況バーを作成したくありません。代わりに、グローバルな進行状況を知らせる単一の進行状況バーが必要です。現時点では、MVC と Observer/Observable について考えることができますが、少しぼやけています :) 誰かが私を正しい方向に向けてくれるかもしれません、ありがとう。

彼らは矛盾していますか？

デカップリングは素晴らしいものであり、達成するのは非常に困難です。ただし、ほとんどのアプリケーションでは実際には必要ないため、高度に結合されたアプリケーションを設計でき、「コンポーネントを分離できない」、「単体テストは苦痛」などの明らかな副作用以外はほとんど変わりません。 arse」など。

どう思いますか？常に分離してオーバーヘッドに対処しようとしていますか？

この WPF アプリケーションのイベントを次のように分離しました。

デカップリングを続ける最善の方法は何ですか?

Shell.xaml:

Bootstrapper.cs:

Shell.xaml.cs:

Customer.cs:

上記のコードShellは、モデルからビューを正常に分離するため、独自の方法で「処理済み」を処理Customer:IPersonするモデルなどにスワップできます。Employee:IPersonそれが最初の目標でした。

でも今：

• Processedビューでイベントを発生させる MenuItem または ListView とも通信でき、それを呼び出す要素である必要さえないように、メソッドを Buttonとの通信から切り離すにはどうすればよいですか、例えば単体テストクラス？
• 送信者 (ボタン) 以外のビューの他の要素を変更するにはどうすればよいですか?たとえば、シェルのステータス バーを変更するにはどうすればよいですか? 2 つの方法があります。
  • すべてのビューを保持するコンテナーを構築し、作成時にコンテナーを Customer に挿入することもできます。その後、顧客はコンテナーを調べて、呼び出し元のビューを必要に応じて操作できます (ただし、イベントを送信したビューと何らかの方法で一致させる必要があります)。コンテナ内のビューは同じものとして）
  • イベントを発生させるときに、イベント引数を使用してビュー全体 (Window オブジェクト) をモデルに送信することもできますが、モデルには、実行時に操作できる領域の種類を (インターフェイスを介して) 知る何らかの方法が必要です。
• このアプリケーションを、よりデカップリングされた設計の方向にどのように継続しますか?
• これは、MVC、MVP、MVVM など、実際にはどのようなパターンですか? ビュー (シェル) とモデル (顧客) しか表示されません。
  • プレゼンターはどのように適合しますか?
  • ViewModel はどのように適合しますか?
  • コントローラーはどのように適合しますか?

私はWebフォーム、C＃、Asp.netを使用しています。ご存知のとおり、このモデルではUIとビジネスロジックが混在していることがよくあります。これらを効果的に分離するにはどうすればよいですか。

使用したい例は次のとおりです。GridViewとDataTableがあります（GridViewはDataTableにバインドされ、DataTableはストアドプロシージャから供給されます）。

GridView（UI）とDataTable（ビジネスロジック）を分離したいと思います。

DataTableのラッパーを作成する価値はありますか？従うことをお勧めできる、証明およびテストされた実用的なパターンはありますか？

経験のある人が光を当てることができれば、それは素晴らしいことです。そして最後に、ASP MVCは現在のところオプションではないので、お勧めしません。

私のデータベースアクセス層はDataTableを返します。これは会社のポリシーであるため、このデータベースレイヤーを使用する必要があることに注意してください。

Entity フレームワークの使用について、友人と少し話し合いました。エンティティ フレームワークをデータレイヤーとして使用して 3 層ソリューションを作成し、データ転送オブジェクトを使用してビジネス層からユーザー インターフェイスに移行するプロジェクトがありました。後で hibernate などを使用してエンティティ フレームワークを変更できるため、それが提供する疎結合が本当に気に入りました。一方、私の友人は、Entity フレームワークの目的は、ユーザー インターフェイスで使用できるようにモデル化することであると主張していました。エンティティ フレームワークをソリューションにどのように結合しますか?

私はいくつかの同様の質問を見てきましたが、私に直接当てはまるものは見当たりませんでしたので、これが重複している場合はご容赦ください.

懸念事項を分離するために、ロジックを使用してビジネス オブジェクトを .dbml ファイルの LINQ to SQL データ オブジェクトにマップしようとしています (これはかなり新しいことです)。ただし、私のビジネス オブジェクトは、対応する LINQ2SQL オブジェクトについて知る必要があるように見えます。xml マッピング ファイルを使用して POCO を使用しようとすることに関するこの記事を読みました。追加のテーブルを作成する必要がある対多の関係。

ビジネス オブジェクトを使用するコードがデータベースについて何も知る必要がないように、ビジネス ロジックでデータ アクセスをかなりうまくカプセル化できます。ビジネス層オブジェクトを変更するか、別のデータ プロバイダー用に新しいオブジェクト (同じインターフェイスを実装する) を作成しない限り、DAL を交換することはできませんでした。

これらのレイヤーを分離するにはどうすればよいですか?