在模型中用数百个问题表示表单的最佳方式是什么

时间:2015-11-21 13:27:32

标签: oop

我正在设计一个收入退税软件。

在模型中表示/存储包含数百个问题的表单的最佳方法是什么?

enter image description here

就本例而言,我至少需要6个型号(T4,T4A(OAS),T4A(P),T1032,UCCB,T4E),可能包含数百个字段。

是通过创建数百个字段吗?在地图中存储值?一个数组?

2 个答案:

答案 0 :(得分:2)

对于这样的情况,整体聚合可能是不可避免的(除非您可以推导出常见字段)。我将排除RDBMS,因为该主题似乎更侧重于较低级别的数据结构和更专有的解决方案,尽管这可能是一个非常有效的选项,可以管理所有这些领域。

在这种情况下,我认为它不再像手术那样只是日常实用。

在这种情况下,从这个角度来看,可能最糟糕的是聚合字段的正式对象,例如classstruct,其中包含大量数据成员。那些往往是最笨拙和最没有吸引力的巨石,因为它们往往具有静态性质。根据语言,声明/定义/初始化可以是独立的,这意味着每个字段需要维护2-3行代码。如果要从文件中读取/写入这些字段,则必须为每个字段编写单独的代码行,并在添加新字段或删除现有字段时维护和更新所有代码。如果在这种情况下你开始接近任何类似于多态需求的东西,你可能不得不为每个字段编写一大堆分支代码,而且也必须维护。

所以我说,到目前为止,静态聚合中的数百个字段是最不可维护的。

如果你需要那些键/值对,只需要存储键的位置和所涉及的算法复杂度的潜在差异,对于我来说,数组和映射在语言无关的意义上对我来说实际上是相同的。无论你做什么,可能在这个巨石中的关键搜索应该是对数时间或更好。大多数语言中的“地图/关联数组”往往具有这种质量。

那些可能更合适,你可以在那些之上实现你喜欢的那种运行时灵活性(比如能够从文件中管理这些并且在没有预先存在的知识的情况下动态添加字段) 。他们在这里会更加宽容。

因此,如果选择在一个类中的一堆字段和类似于地图的字段之间,我建议去寻找地图。它的动态性质对于这些类型的情况将更加宽容,并且通常远远超过编译时的好处,例如,检查以确保字段实际存在并且否则产生语法错误。如果我们只是接受它将在运行时发生,那么这种检查很容易重新添加。

可能使场解决方案更具吸引力的一个例外是,如果您涉及反射和更动态的技术来动态生成具有适当字段的对象。然后,您可以在运行时获得这些动态优势和灵活性。但是,初始化结构可能会更加笨拙,可能涉及更多地依赖于重型(并且可能计算成本很高)内省和类型操作以及代码生成机制,并最终得到更难以处理的更加时髦的代码。维护。

所以我认为最安全的选择是地图或关联数组,以及一种语言,可让您轻松添加新字段,检查现有字段等,并且转换速度非常快。如果该语言本身并不具备该质量,您可以查看外部文件以动态添加字段,并只维护该文件。

答案 1 :(得分:2)

一种非常通用的方法可以是XML

XML允许你

  • 将您的数据嵌套到任何程度
  • 组合值和元信息(属性和元素)
  • 使用XSD详细描述您的数据
  • 将其存储在外部
  • 轻松维护
  • 甚至将其与其他信息相结合(查看处理说明)
  • 和(最后但并非最不重要)以与modell ...
  • 几乎相同的格式存储真实数据
  • 和(laster但即使不是leaster :-))还有XSLT将您的XML数据转换为任何其他格式(例如HTML以便于演示)

所有主要语言和数据库系统都支持XML。

另一种方式可能是典型的parts list(或bill of materials/BOM

此树结构 - 通常 - 实现为具有自引用parentID的表。使用这样的表需要大量的递归...

强烈建议您保存数据类型安全。使用字符存储格式和类型标识符(这意味着你必须在这里和那里强制转换所有值),或者通过引用使用不同的类型安全边表。

更多 - 如果要从列表中填充数据 - 您应该定义一个数据源以动态加载选择列表。

<强> Conclusio

最适合您的主要取决于您的需求:模式多久会改变一次?有多少规则可以保证数据的完整性?你在使用RDBMS吗?您使用的是哪种语言/工具?