Arn*_* F. 4 c# frameworks compact-framework namespaces
我有一个需要在Compact .NET Framework 3.5和.NET Framework 3.5中编译的项目(实际上只有2个项目,只编译两者之间发生变化的选项).
问题是,CF .NET中缺少某些类,所以我手动创建它(并实现了.NET中可用的所有类成员)
一个例子:FtpWebRequest/FtpWebResponse类.
写这样的东西是不好的(如果是,为什么?):
#if CFNET35 // Only if we are in Compact Framework 3.5 mode
namespace System.Net
{
public class FtpWebRequest : WebRequest
{
// ...
}
public class FtpWebResponse : WebResponse
{
// ...
}
}
#endif
Run Code Online (Sandbox Code Playgroud)
我敢肯定,在CF.NET35中,这些方法永远不可用,我可以编写它吗?
我会写这个是为了避免在项目中使用我的库时发生名称冲突.
它允许我在其他项目中总是白using System.Net;求问我使用哪个框架...
谢谢 !
几个月后,我会评估我使用的策略.
如上所述,我通过进行条件编译来覆盖System(.Net)命名空间,所以我有两个DLL(一个用于CF.NET,一个用于.NET)
这也包括我使用这个DLL的所有应用程序都是双重的(每次都是CF.NET应用程序和一个包含相应库的.NET应用程序).
所以,这是一个坏主意,我有很多项目是双重的,而且.NET应用程序可以直接包含和使用CF.NET库的方式是不必要的.
此外,我还没有注意的是,如果一个.NET应用程序包含一个带有覆盖系统命名空间的CF.NET库,由于类名冲突,它的初始化将失败...
因此,提供通用接口的EPIC FAIL是管理此案例的最佳方式.
我可能会避免使用System命名空间来编写自定义代码.我见过尝试这样做的开源库,它通常会导致头痛.
您可能最好创建一个在完整框架和紧凑框架之间共享的接口,然后在完整和CF中实现接口,使用内置的System类或您自己编写的类来提供所需的功能.
这可能看起来有点矫枉过正,但如果System.Net中的某些内容发生变化,您将来会更安全.您的调用代码应该只引用该接口,您可以根据您所在的平台插入任一实现.
// Shared interface
public interface IFtpUtil
{
SomeFileObject GetFile(SomeArgument a);
void PutFile(SomeFileObject f, SomeArgument a);
}
// Full framework implementation
public class FullFtpUtil : IFtpUtil
{
public ... GetFile(...)
{
// Use System.Net classes from full framework
}
public ... PutFile(...)
{
// Use System.Net classes from full framework
}
}
// Compact framework implementation
public class CompactFtpUtil : IFtpUtil
{
public ... GetFile(...)
{
// Use your own FTP classes
}
public ... PutFile(...)
{
// Use your own FTP classes
}
}
Run Code Online (Sandbox Code Playgroud)
我不会这样做; 不是因为任何具体的技术原因,而是因为它可能会引起一些重大的混乱. 没有人希望自定义类驻留在System命名空间中.
System命名空间中的类已被许多人广泛测试和使用,因此如果团队System.Net.FtpWebRequest中的其他人在他们的代码中使用他们的代码并且他们的代码不起作用,他们将(并且应该)首先在他们自己的代码中搜索错误.经过几个小时的搜索,当他们发现错误出现在显然内置的系统类中时,他们会生你的气.