停止我的＆QUOT;实用＆QUOT;从不同的架构之间提供错误 [英] Stop my "Utility" from giving errors between different architectures

问题描述

我主要程序在WinForms的环境，除其他事项外，非常经常使用 TreeView控件控制。

I primarily program in the WinForms environment and, among other things, very often use the TreeView control.

既然如此，我有我开发了一个实用工具类，它有很多我最常用的功能 - 像一个DataTable转换成可输出到一个文本文件中的字符串delimitted，弹出一个Save-为对话框并返回用户选择的文件名或指定的树状返回检查树节点列表等。

That being the case, I have a Utility class I developed which has a lot of my most common functions - Things such as converting a DataTable to a delimitted string that can be outputted to a text file, popping up a "Save-As" dialog and returning the filename the user chooses or returning a list of checked treenodes from a specified treeview, etc.

，树节点有WinForms和ASP之间不同的属性。

Given that I have this utility class, I am now trying to add it to an ASP.Net application and it is giving me a lot of obvious errors with, for example, TreeNode having different properties between WinForms and ASP.

现在，我知道我的第一个和最聪明的回应应该是所有这些不同的功能分离出来，成为独立的实用程序文件和库并将其添加为IS-需要/适用于每一个应用程序 - 我理解的优点和逻辑这一点，但我的问题是更多关于创建类本身的理论。

Now, I know the first and most intelligent response to me would be to separate out all these different functions into separate utility files and libraries and add them as-is-needed / applicable to each application - I understand the benefits and logic of that, but my question is more about the theory of creating the class itself.

有没有一种方法来创建一个类，将包括〔实施例，WinForms的对象，我仍然可以将其添加到ASP应用程序没有它示数？
换句话说，我是不会使用这些功能，因为它们显然不会为这种架构的工作，但有没有办法出现只是因为物体出现错误的这种架构停止错误，只是让编译器接受该文件 - 那我就用我知道这个架构是恰当的功能

Is there a way to create a class that will include, for exmaple, WinForms objects and I could still add it to an ASP application without it erroring? In other words, I won't use those functions since they obviously won't work for this architecture, but is there a way to stop the errors from appearing just because the objects appear wrong to this architecture and just have the compiler accept that file - Then I'll just use the functions I know ARE appropriate for this architecture?

正如我的实用工具类的函数在WinForms的罚款在ASP中一个愚蠢的例子，但错误：

As a stupid example of a function in my Utility class that's fine in winForms, but Errors in 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

在这种情况下，'名称'不'System.Web.UI.WebControls.TreeNode

修改：
只是为了澄清 - 我的理解这个具体情况不好的编程习惯。我的问题是更使有关努力学习，如果有一种方法来隐藏功能的缺失从编译器库，以便一类可以多架构中，而无需用于图书馆增加对你会不会使用函数/需要。

EDIT: Just to clarify - I understand the bad programming practice on this specific situation. My question is more-so about trying to learn if there was a way to "hide" functions missing libraries from the compiler so a class could be used within multiple architectures without the need for adding in libraries for functions you won't be using / needing.

我希望这个问题有意义，感谢您的专业知识。

I hope this question makes sense and thanks for your expertise.

推荐答案

问题是在你的实用类，根据您的例子中，就是你是不是的明确的告诉应用程序哪种类型你是指因此它只能作一个假设，这是它找到的第一个。换句话说，声明类型时，让你的效用函数可以更加使用完全限定路径的具体的例如。

The problem is in your utility class, based on the example you have shown, is that you aren't explicitly telling the application which type you are referring to therefore it can only make the assumption that it's the first one it finds. In other words, use fully qualified paths when declaring types so your utility functions can be more specific e.g.

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

不过，这则凸显了另外一个问题 - 作为你的公用事业类从特定库使用的类型变得相关在它一样，任何的lib /应用程序中引用您的工具库。你需要问的是这个问题，是不是真的值得一对夫妇的实用方法？

However, this then highlights the other issue - as your utility class uses types from particular library it becomes dependant on it, as does any lib/application referencing your utility lib. The question you need to ask is, is it really worth it for the sake of a couple of utility methods?

现在，我知道我的第一个和最聪明的回应应该是所有这些不同的功能分离出来，成为独立的实用程序文件和库并将其添加为IS-需要/适用于每一个应用程序 - 我理解的优点和逻辑那

Now, I know the first and most intelligent response to me would be to separate out all these different functions into separate utility files and libraries and add them as-is-needed / applicable to each application - I understand the benefits and logic of that

那么为什么要反对呢？正如你可以看到有做你想要的东西没有的清洁的方式，无论哪种方式，你将要添加依赖于不需要的库。

Then why go against it? As you can see there is no clean way of doing what you want, either way, you are going to be adding dependencies to libraries that are not required.

我看到你的code分裂成精美的3个独立的工具库即。

I see your code splitting up nicely into 3 separate utility libraries i.e.

• 工具 - 只引用核心类型


• Utilities.Web - 参考特定Web-控制


• Utilities.WinForms - 参考文献的形式，具体的控制

• Utilities - References core types only
• Utilities.Web - References web-specific controls
• Utilities.WinForms - References forms-specific controls

如果你是坚定的，你想这样做，这样再有就是始终使用的编译器指令如

If you are adamant you want to do it this way then there is always the possibility of using compiler directives e.g.

#if TARGET_WINFORMS

... // win form specific methods

#endif

#if TARGET_WEB

... // web specific methods

#endif

... // core methods

这将允许您编译工具来针对特定的体系结构，从根本上剔除任何不必要的code。它涉及到一点点额外的内务管理，但它会做的伎俩。

This would allow you to compile your utility to target a specific architecture, essentially stripping out any unnecessary code. It involves a little extra house-keeping but it would do the trick.

这篇关于停止我的＆QUOT;实用＆QUOT;从不同的架构之间提供错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！