代码之家  ›  专栏  ›  技术社区  ›  Ami

ASP.NET MVC为图表生成XML数据源

  •  0
  • Ami  · 技术社区  · 15 年前

    我必须构建一个XML输出,它表示一个为放置在视图中的灵活图表结构化的数据。 我有几个选择:

    1. 让控制器创建XML(使用来自数据库的数据),并将其返回到一个实际上不做任何事情的视图,因为一切都已就绪。

    2. 将视图从数据库强类型化到数据模型,并在视图中声明性地呈现XML。

    3. 创建一个HTML扩展方法,该方法将包含创建XML的逻辑,并在视图中使用它。

    在关注分离方面,最好的选择是什么? 在将来,我不希望对XML结构做太多的更改,可能是偶尔的。 我倾向于选择选项1,因为它更具可测试性,并且我对准备XML数据的控制器感到更舒服。

    3 回复  |  直到 15 年前
        1
  •  0
  •   Razzie    15 年前

    我会选择1号选项,因为我觉得它最适合MVC模式。视图不负责基于某些数据模型创建XML文件。这是业务逻辑,因此在控制器中更好。

    同样重要的是,如您所说,如果让您的控制器创建XML文件,您可以为它创建一个单元测试,它断言输出XML是有效的,包含所有必要的节点,等等。

        2
  •  0
  •   Mark Dickinson    15 年前

    选项2是最好的。你的模型有数据,你的控制器要求它并提供给视图。这个视图只有一个标签来说明它的位置。对我来说,这就是分心。

    看到Razzie的答案,我也喜欢1,我认为模型必须提供一些方法,将某些实体类(图表结果)序列化为XML,以便强类型视图能够使用它。

    不管怎样,我希望答案有帮助,基本上我认为3不是很好。-)

        3
  •  0
  •   WestDiscGolf    15 年前

    我想说这取决于你对什么更满意,因为选项1和2都是可行的。人们会说选项1很好,因为您可以使用XML编写器来确保返回有效的XML,人们会说选项2有效,因为MVC完全控制视图中呈现的内容(可以是XML)。

    但是,我个人会使用选项1的一个变体来保持功能独立于控制器,并将其作为一个独立的实用程序方法来接收数据并输出XML。这将更容易测试,但如果将来需要,也可以从代码中的其他地方调用。除此之外,它还可以使控制器中的代码保持干净。

    我同意马克的观点,我认为选项3不是一个好方法。

    这只是我的想法,希望这有帮助:—)