我正在解析电子邮件并使用ORM将它们插入数据库(确切地说是NHibernate).虽然我目前的方法在技术上有效,但我不是很喜欢它,但不能提供更好的解决方案.该电子邮件包含50个字段,并从第三方发送,看起来像这样(显然是一个非常短的虚拟样本).
Field #1: Value 1 Field #2: Value 2
Field #3: Value 3 Field #4: Value 4 Field #5: Value 5
Run Code Online (Sandbox Code Playgroud)
我的问题是,通过解析这么多字段,数据库表是一个绝对的怪物.我无法使用任何种类的关系创建适当的模型AFAIK,因为发送的每封电子邮件都是静态数据,并且不依赖于任何其他来源.
我唯一的想法是找到每个字段之间的共性,并将它们分成更易于管理的块.每个实体说10~字段,总共5个实体.然而,我并非非常喜欢这个想法,因为我所做的就是建立一对一的关系.
管理大量不受控制的房产的好方法是什么?
有什么想法吗?
小智 6
创建2个表:1表示主对象,另一个表示字段.这样,您可以根据需要以编程方式访问每个字段,并且对象模型看起来并不令人讨厌.
但这只是我的头脑; 你有一个奇怪的问题.
如果数据返回到您可以轻松解析的文件中,那么您可以创建一个命令行应用程序,该应用程序将生成脚本和c#,然后您可以执行并复制,粘贴到您的程序中.从html页面创建表格中的属性时我已经这样做了(就像我最近必须做的那样)
如果50个属性实际上是关于这个实体的唯一且离散的数据,我看不出在一个对象上拥有这50个属性(即使听起来很多)的问题.例如,Type类具有大量与其数据相关的布尔属性(IsPublic等).
备择方案:
好吧,立即想到的一个选项是使用动态对象并重写TryGetMember来查找"属性"名称作为键值对字典中的键(其中存在50个键值对的实际设置).当然,弄清楚如何将你的ORM映射到你的实体是另一个问题,你会失去智能感知支持.
然而,只是把想法扔到那里.
| 归档时间: |
|
| 查看次数: |
379 次 |
| 最近记录: |