0

グラフを描画するクラスを含むプロジェクトがあります。クラスは次のようになります。

using System.Web.UI.DataVisualization.Charting;

namespace MyNameSpace
{
    public static class Utilities
    {
        public static void DrawOnGraph (Chart ourChart,
                                        // ...more parameters...
                                        )
        {
            ChartArea our_area = new ChartArea("Main");
            // Draw things
        }
    }
}

これは、同じソリューション内の別のプロジェクトに含まれる Web アプリケーションによって引き起こされます。Webフォームに正確に同じ入力を使用して正確に同じグラフを描画するフォームアプリケーションを作成する必要があります。プロジェクトを2番目のソリューションに含めたいと思います。しかし、クラスは次のようにする必要があります:-

using System.Windows.Forms.DataVisualization.Charting;

namespace MyNameSpace
{
    public static class Utilities
    {
        public static void DrawOnGraph (Chart ourChart,
                                        // ...more parameters...
                                        )
        {
            ChartArea our_area = new ChartArea("Main");
            // Draw things
        }
    }
}

同じプロジェクト/クラス/コードを両方に使用できるかどうかを知りたいのですが、当然のことながら、コードを2つの異なる場所にカットアンドペーストしたくないので、唯一の違いはusingディレクティブです。

上記の ChartArea など、(代替) 名前空間のオブジェクトの関数内に宣言があるため、ジェネリックを使用する方法がわかりません。どの行が必要かは、プロジェクト自体ではなく、プロジェクトが含まれているソリューションに依存するため、条件付きコンパイルを使用する方法がわかりません。循環参照が作成されるため、呼び出し元プロジェクトを参照できません。Web グラフを Windows グラフにキャストすることもできません。

私が管理できた最善の方法は、両方のusingディレクティブを提供することですが、現在取り組んでいるソリューションに応じて、そのうちの 1 つをコメントアウトすることです。しかし、それは私にはあまり満足のいくものではないようです。より良い方法はありますか？それとも、怠けてコードを 2 回書くべきではありませんか?

4

4 に答える 4

2

描画ロジックの上に独自の抽象化を作成し、ラッパーパターンを使用して両方のグラフをカプセル化できます。次に、抽象化に対してコーディングし、各フォームとWebプロジェクトに実装フォームを提供します。グラフの描画ロジックは、このアプローチを正当化するのに十分複雑であると思います。これを実装すると、グラフに変更を1か所で導入できるようになり、両方のアプリケーションに影響します。

于 2012-07-26T10:12:03.447 に答える
2

私が考えることができる最高の魂は、クラスのラッパーインターフェイスを作成することです。これは、両方System.Web.UI.DataVisualization.ChartingをSystem.Windows.Forms.DataVisualization.Charting提供/必要とします。次に、インターフェイスの2つの実装を提供します。1つはフォーム用、もう1つはUI用です。これによりUtilities、正確な実装を知らなくてもインターフェイスメソッドを呼び出したり、UIとフォームの両方のコードを共有したりできます。

于 2012-07-26T10:12:47.907 に答える
1

1つはWeb用です

using System.Web.UI.DataVisualization.Charting;

もう1つはWindows用です

using System.Windows.Forms.DataVisualization.Charting;

問題は、彼らが彼らのプラットフォームに関連するクラスを使用することであるため、あなたはそれを達成できるとは思わない

私のアドバイスは、共通の機能をWebまたはWindowsに依存しないライブラリに分離し、これをWeb用とWindows用の2つの異なるソリューションに使用することです。これにより、コードの繰り返しを2回減らすことができます。

アップデート ：

もう1つのオプションは、Windowsコントロールライブラリとして記述し、WebアプリケーションでDLLとして使用できるようにすることです。この例をご覧くださいhttp://www.beansoftware.com/ASP.NET-Tutorials/Place-Windows-Control-To-Web-Form.aspx

于 2012-07-26T10:10:55.880 に答える
1

Series、ChartArea などの操作を含む、Web.UI と Windows.Forms Charting のそれぞれの API の「同一」部分をコードが呼び出す場合は、条件付きコンパイルを使用できます。

コードを 2 回コンパイルするだけです。1 回目はWeb.UI Charting を使用し、もう 1 回は Windows.Forms Chartingを使用します。条件付きコンパイルを使用してアセンブリ参照を有効/無効にすることで、1 つのアセンブリが WinForms に基づくアプリケーションと他の WebUI Charting アプリをターゲットにします。

別の方法としては、Windows.Forms Charting API だけでうまくいく場合もあります。たとえば、 img要素のsrc属性など、html が必要なときはいつでもChart.SaveImage (..) を使用するだけです。の上。しかし、これには欠点があります。

Web.UI と Windows.Forms Charting のそれぞれの API と機能が十分に重複していないため、これらの代替手段は両方とも制限されています。さらに、SaveImage() は、Web アプリに Windows.Forms アセンブリや余分な操作による負荷をかけたくないため、さらに制限されます。

それにもかかわらず、条件付きコンパイル アプローチは、Web アセンブリとフォーム アセンブリが分岐した場合でも機能します。共有コードを維持できます (ただし、Web またはフォーム用に条件付きでコンパイルされます) が、各ライブラリは Web またはフォーム ターゲットに固有の新しいコードを蓄積します。このアプローチは、構成を構築するための優れたアプローチで最もうまく機能します。構成を構築するための優れたアプローチがあれば、他のアプローチよりも維持および拡張が容易になると思います。

于 2013-07-02T21:48:04.787 に答える