我可以将类型限制为仅包含可为空的属性吗？
我有这样的类，其中所有属性都必须是可为空类型。是否可以为 Sessions 类属性添加设计（而不是运行时）时验证以检查添加的新属性是否具有可为空类型？如果属性不具有可空类型，编译器应该给出错误并且不编译代码。
public class Sessions : SessionInfo<Sessions>
{
public int? UserId { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public string Email { get; set; }
public string OldEmail { get; set; }
public bool? UserManager { get; set; }
public bool? UserManagerVisible { get; set; }
public bool? TransactionCall { get; set; }
}
I have such class where all properties must be nullable types. Is it possible to add design(not runtime) time validation for Sessions class properties to check is added new property has nullable type? The compiler should give error and not compile code if property will not have nulable type.
public class Sessions : SessionInfo<Sessions>
{
public int? UserId { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public string Email { get; set; }
public string OldEmail { get; set; }
public bool? UserManager { get; set; }
public bool? UserManagerVisible { get; set; }
public bool? TransactionCall { get; set; }
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，您有点不正确，因为在您的示例中只有
int?和bool?属性是可空。String是一个引用类型，它可以接受null（与任何引用类型一样），但它不能可为空本身（C# 一词的含义）。其次，不，没有任何方法可以在编译类型中“检查”类定义，坦率地说，这对我来说没有任何意义。您是否希望在某处编码此限制？那么，如果您最终决定放弃它怎么办？你会改变这个“约束”代码吗？但如果只通过编辑代码就可以解除限制，那还有什么意义呢？这很像在门上装一把锁，只是为了把钥匙放在里面。
是的，您可以使用 FxCop 等静态分析工具来解决此问题，如 Anders 所建议的 ，但从我的角度来看，这样做的必要性凸显了代码中的设计问题。创建此类规则通常是为了在项目级别强制执行某些设计策略，而不是限制代码中的单个类。
我对
SessionInfo的作用很好奇。它是否通过反射遍历每个属性？如果您解释了原来的问题，我们可以帮助您提出更好的解决方案。使用奇怪的重复模板模式< /a> 还表明您可能是 过度解决问题的人类型。你想实现什么目标？
At first, you are slightly incorrect because in your example only
int?andbool?properties are nullable.Stringis a reference type, it can acceptnull(like any reference type) but it isn't nullable per se (in the C# sense of the word).Secondly, no, there isn't any way to “check” the class definition at compile type and frankly it doesn't make any sense to me. Do you expect this restriction to be coded somewhere? So what if you decide to drop it eventually? Would you change this “constraining” code? But then what is the point of the restriction if it can be lifted by just editing the code? It's much like installing a lock on the door only to keep keys in it.
Yes, you can work around this by using a static analyzer tool like FxCop, as suggested by Anders, but from my point of view the very need for this highlights a design problem in your code. Such rules are usually created to enforce certain design policy on the project level, not to constrain a single class in your code.
I'm curious about the role of
SessionInfo<T>. Does it go over each property with Reflection? If you explained your original problem, we could help you come up with a better solution. The use of Curiously Recurring Template Pattern also suggests that you may be the type of person to oversolve the problems.What are you trying to accomplish?
首先为此编写一个自定义 FxCop 规则（对规则进行硬编码以仅检查 Sessions 类，或者使用 FxCop 规则将用来查找相关类的自定义属性。
在 binarycoder 上有一个关于编写自定义 FxCop 规则的很好的教程。这是一个示例，其中规则检查类中每个字段的命名
http://www.binarycoder.net/fxcop/html/ex_classfieldnameprefixes.html
编写规则后，右键单击您的项目 ->特性。转到代码分析选项卡。选中“在构建时运行代码分析”。确保规则集包含您的自定义规则。
现在，FxCop 将对项目的每次编译运行静态代码分析，并在 Visual Studio 的“错误列表”选项卡中报告警告以及编译警告。
First write a custom FxCop rule for this (either hard code the rule to check only the Sessions class, or use a custom attribute that the FxCop rule will use to find the classes in question.
There is a good tutorial on writing custom FxCop rules at binarycoder. Here is an example where the rule checks the naming of every field in a class
http://www.binarycoder.net/fxcop/html/ex_classfieldnameprefixes.html
Once your rule is written, right click your project -> properties. Go to the Code Analysis tab. Check "Run code analysis on build". Make sure the Rule Set includes your custom rule.
Now FxCop will run static code analysis on each compile of the project, and warnings will be reported in the "Error List" tab in visual studio, together with compilation warnings.