3

アーカイブしたいもの：

  • EntityClasses（純粋なデータ）を保持するサービスアセンブリ（プロジェクト）。
  • それらのエンティティを独自の目的のために拡張するGUIアセンブリ-GUIのランタイム情報。

私が試したこと：

  • 派生（GuiはクラスExtendedEntity：Service.BaseEntityを定義します）

    私にとって最も一般的で唯一の実行可能な方法のようですが、：

    サービスからデータを取得した後にService.BaseEntityをExtendedEntityに変換するのは面倒です。リフレクションを使用してベースエンティティインスタンスに基づいて新しいExtendedEntityインスタンスを生成することでこれを「回避」できますが、これは「適切な」ソリューションにはなりません。

  • 部分クラス

    それがクロスアセンブリで機能しないという事実を除いて、まさに私が探しているものです。

リフレクションの不正行為なしに適切でクリーンな解決策を見つけるのに役立つヒントをいただければ幸いです=）

4

3 に答える 3

1

これは直接的な答えではありませんが、デザインについてもう少し考えてみてください。なぜあなたのGUIはデータストレージの仕組みについての深い知識を必要とするのですか？通常、UIとデータアクセスが緩く結合されていることを確認するために非常に懸命に取り組んでいるため、すでに機能しているものを壊すことを恐れずにどちらかに変更を加えることができます。実装しようとしている設計は、後で予期しない問題を引き起こす可能性があります。

このタイプのものに適した一般的なパターンの1つは、リポジトリパターンと呼ばれます。基本的に、サービスアセンブリ（リポジトリ）には、特定のデータストアにデータを出し入れするために必要なすべての知識が含まれます。データの「形状」はよく知られており、GUIとリポジトリの間で共有されます。サービスアセンブリは、CRUD操作をGUIで利用できるようにし、GUIはリポジトリへの参照を保持し、リポジトリのメソッドを呼び出して、必要なデータをフェッチ、作成、更新します。

ここに、緩い結合、リポジトリパターン、および依存性注入のアイデアを開始するためのリンクがいくつかあります。

凝集度と結合度

依存性注入とは

良いリポジトリパターンチュートリアルとは

于 2011-10-16T01:57:24.250 に答える
0

GUIアセンブリにエンティティクラスの拡張メソッドを定義させることができます。適切なusingディレクティブがあれば、これは、消費するコードがメソッドが実際にどこで定義されているかを知らないか、気にしないことを意味します。

少し厄介なのは拡張プロパティが存在しないことです。したがって、概念的にプロパティであるものでさえ、メソッドとして実装する必要があります。

これは少し次のようになります。

  • 稼働中のアセンブリ

    public class FooDTO
{
    public string Name { get; set; }
}

  • GUIアセンブリで

    internal static class Extensions
{
    // Artificial example!
    public static int GetNameLength(this FooDTO foo)
    {
        return foo.Name.Length;
    }
}

// Consuming code
int myFooNameLength =  myFooDTO.GetNameLength();
于 2011-10-07T14:52:16.360 に答える
0

逆コンパイルはオプションですか？はいの場合は、PostSharpやMono Cecilなどを使用して、問題のクラスを書き直し、そこに必要なコードを追加できます。派生のような標準のOOアプローチを使用したくない理由は私が好奇心をそそります。それは間違いなくハッキングではありません。

「最もクリーンな」OOソリューションは、集計を使用して、オブジェクト内にEntityクラスをカプセル化することです。ここで、データで実行できることと、データを操作またはクエリする方法を完全に制御できます。クラスは適切な抽象化で必要なすべての操作をサポートするのに十分強力であるため、集約クラスが内部Entityクラスを公開する必要がなくなったときに「天国」に到達しました。

拡張したいクラスが封印されている場合は、これらのクラスの作成者が拡張を望まなかった理由をよく考える必要があります。

Eric Lippertは、封印されたキーワードの使用法について素晴らしい投稿をしています。

..。

今、私は開発者がただ物事を成し遂げたいだけの非常に実用的な人々であることを認識しています。どんなクラスでも拡張できるのは確かに便利です。典型的な開発者は「IS-A-SHMIZ-A、私はただConfusticatorをFroboznicatorクラスに叩きつけたい」と言います。その開発者はハッシュテーブルを作成して相互にマッピングすることができますが、アイテムを削除するタイミングなどを心配する必要があります。これはロケット科学ではありませんが、機能します。

明らかに、ここにはトレードオフがあります。トレードオフは、開発者が古いオブジェクトをプロパティバッグとして扱うことを許可することで少し時間を節約できるようにすることと、適切に設計されたOOPtacularの完全な機能を備えた、堅牢で安全な予測可能でテスト可能なフレームワークを開発することです。妥当な時間-そして私は後者に大きく傾くつもりです。あなたは何を知っているので？それらの同じ開発者は、私たちが彼らに与えるフレームワークが、中途半端で、もろく、安全でなく、完全にテストされていないために彼らを遅くすると、ひどく不平を言うでしょう！

..。

あなたの、アロイス・クラウス

于 2011-10-15T23:41:46.527 に答える