在 FileHelpers 映射类中使用数组
我一直在寻找一种方法来允许 FileHelpers 映射类的一个元素成为特定长度的数组。
例如,我有一个这样的类:
[DelimitedRecord(",")]
public class Example
{
public string code;
public int month;
public int day;
public double h1;
public double h2;
public double h3;
public double h4;
}
值 h1-h4 作为一个简单地称为“h”的数组确实更有意义。 这也将使处理文件变得更容易。 我还知道我正在阅读的文件中将始终包含这些字段,并且只有这些字段。
有人找到了在 FileHelper 映射类中包含数组的方法吗?
I have been searching for a way to allow one element of my FileHelpers mapping class to be an array of specific length.
For instance, I have a class like this:
[DelimitedRecord(",")]
public class Example
{
public string code;
public int month;
public int day;
public double h1;
public double h2;
public double h3;
public double h4;
}
The values h1-h4 would really make more sense as an array simply called 'h'. It would make processing the file a little easier as well.
I also know that the file I am reading will always have these, and only these, fields in it.
Has anyone figured out a way to include arrays in your FileHelper mapping classes?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
FileHelpers 记录类需要公共字段。 记录类不应被视为应遵循最佳编码实践的普通 C# 类; 相反,它只是用于描述导入文件结构的语法。
建议使用 FileHelpers 的过程是循环遍历生成的
Example[]
数组,并将所需的字段映射到更普通的类(使用属性而不是公共字段)。 此时,您可以将 H1-H4 值复制到数组属性中。FileHelpers record classes require public fields. The record class should not be considered as a normal C# class that should follow best coding practices; rather it is just a syntax for describing an import file's structure.
The recommended procedure with FileHelpers would be to loop through the resulting
Example[]
array and map the fields you need to a more normal class (with properties instead of public fields). At this point you can copy your H1-H4 values to an array property instead.我对相关工具一无所知,但是(假设这不是该工具的限制)我真的怀疑公共领域的智慧。 属性还可以让您有机会调整值:
再次 - 我不知道该工具是否支持这一点,但这将是实现它的可行方法。 当然,“h”值与直接成员一样好(实际上,效率稍微高一些 - 堆上没有数组,也没有取消引用):
I don't know anything about the tool in question, but (assuming it isn't a limitation of the tool) I really doubt the wisdom of public fields. Properties would also give you the opportunity to shim the values:
Again - I have no idea if the tool would support this, but it would be a viable way of implementing it. Of course, the "h" values would do just as well (actually, slightly more efficient - no array on the heap and no de-reference) as direct members: