0

私は主に WinForms 環境でプログラミングを行っており、特にコントロールを頻繁に使用していTreeViewます。

その場合、私が開発したユーティリティ クラスがあり、これには多くの最も一般的な機能があります。たとえば、DataTable をテキスト ファイルに出力できる区切り文字列に変換したり、[名前を付けて保存] ダイアログをポップアップしたりします。ユーザーが選択したファイル名を返すか、指定されたツリービューからチェックされたツリーノードのリストを返します。

このユーティリティ クラスがあるので、それを ASP.Net アプリケーションに追加しようとしています。たとえば、TreeNodeWinForms と ASP の間でプロパティが異なるなど、多くの明らかなエラーが発生しています。

さて、私への最初の最も賢明な対応は、これらのさまざまな機能をすべて個別のユーティリティ ファイルとライブラリに分離し、必要に応じて/各アプリケーションに適用できるように追加することです。その利点とロジックを理解しています。しかし、私の質問は、クラス自体を作成する理論に関するものです。

たとえば、WinForms オブジェクトを含むクラスを作成する方法はありますか?エラーを発生させずに ASP アプリケーションに追加できますか? 言い換えれば、これらの関数は明らかにこのアーキテクチャでは機能しないため使用しませんが、このアーキテクチャに対してオブジェクトが間違っているように見え、コンパイラにそのファイルを受け入れさせるだけでエラーが表示されないようにする方法はありますか? - 次に、このアーキテクチャに適しているとわかっている関数を使用しますか?

私の Utility クラスの関数の愚かな例として、winForms では問題ないが、ASP ではエラーが発生します。

Public Shared Function CreateTemporaryNode(ByVal NodeName As String) As TreeNode
    Dim TempNode As New TreeNode

    TempNode.Name = NodeName
    TempNode.Text = NodeName

    Return TempNode
End Function

この場合'Name' is not a member of 'System.Web.UI.WebControls.TreeNode'

編集：明確にするために-この特定の状況での悪いプログラミング慣行を理解しています。私の質問は、使用しない関数のライブラリを追加する必要なく、複数のアーキテクチャ内でクラスを使用できるように、ライブラリが欠落している関数をコンパイラから「隠す」方法があるかどうかを学習しようとすることです /必要です。

この質問が理にかなっていることを願っています。あなたの専門知識に感謝します。

4

3 に答える 3

3

問題は、あなたが示した例に基づいて、あなたのユーティリティクラスにあります.あなたが参照しているタイプをアプリケーションに明示的に伝えていないため、それが最初に見つかったものであると仮定することしかできません. つまり、型を宣言するときに完全修飾パスを使用して、ユーティリティ関数をより具体的にすることができます。

Public Shared Function CreateTemporaryNode(ByVal NodeName As String) As System.Windows.Forms.TreeNode
    Dim TempNode as New System.Windows.Forms.TreeNode
    TempNode.Name = NodeName
    TempNode.Text = NodeName
    Return TempNode
End Function

ただし、これにより他の問題が浮き彫りになります。ユーティリティ クラスは特定のライブラリの型を使用するため、ユーティリティ ライブラリを参照するライブラリ/アプリケーションと同様に、それに依存するようになります。あなたが尋ねる必要がある質問は、いくつかのユーティリティメソッドのために本当に価値があるかということです.

さて、私への最初の最も賢明な対応は、これらのさまざまな機能をすべて個別のユーティリティ ファイルとライブラリに分離し、必要に応じて/各アプリケーションに適用できるように追加することであることを知っています。その利点とロジックを理解しています。

では、なぜそれに反対するのですか？ご覧のとおり、必要でないライブラリに依存関係を追加することになります。

コードが 3 つの個別のユーティリティ ライブラリにうまく分割されているのがわかります。

  • Utilities- コア タイプのみを参照
  • Utilities.Web- Web 固有のコントロールを参照
  • Utilities.WinForms- フォーム固有のコントロールを参照

あなたがこの方法でそれをやりたいと断言しているなら、コンパイラディレクティブを使用する可能性が常にあります。

#if TARGET_WINFORMS

... // win form specific methods

#endif

#if TARGET_WEB

... // web specific methods

#endif

... // core methods

これにより、ユーティリティをコンパイルして特定のアーキテクチャをターゲットにし、本質的に不要なコードを取り除くことができます。少し余分なハウスキーピングが必要ですが、うまくいくでしょう。

于 2013-01-17T15:11:41.863 に答える
1

クラス ファイルを直接コピーして使用しても、クラス内のコードは依存アセンブリ (WinForms) への参照なしではコンパイルされないため、機能しません。

ただし、機能するのは次のとおりです。

  • クラスを保持する別のプロジェクトを作成します。このプロジェクトには、webforms アセンブリと winforms アセンブリへの参照が必要です。
  • コアのクラスを作成します。
  • WinForms 用のクラスを作成します。
  • Web 用のクラスを作成します。

このようにして、すべてのコードを 1 つのアセンブリに追加できます。

これが機能するのは、Web サイトから WinForms クラスを使用しない場合、依存する winform アセンブリが読み込まれないためです (これは、読み込めないか、実行中の Web サイト プロセスで必要とされないためです)。

于 2013-01-17T15:25:24.040 に答える
0

まったく別の種類のオブジェクトなので、これは不可能だと思います。

もちろん、そのコンテキスト内では同じ責任がありますが、ASP Web フォームで Winform Treenode を使用することはできません。

于 2013-01-17T15:08:03.903 に答える