愈发强大亦或后退?4年后MVC何去何从

    文章来源:中国互联 更新时间:2013-8-14 14:28:02
分享:
我已经有3年时间主要从事于使用NServiceBus来开发SOA消息系统,而中断了在Web应用程序方面的工作,而就在最近又回归到一个MVC项目上来了。许多东西已经发生了改变,但是也有许多东西一如从前。
  我们在MVC中尝试使用的大多数东西(强类型视图stringly-type view,输入/输出帮助 input/output helper,元数据驱动输出metadata-driven output 等等)使得它成为我围绕AutoMapper所得到的诸多疑问的核心——我们仍然要使用它么,等等这些问题。简短的回答是yes,意味深长的回答则是“看情况”。由于AutoMapper旨在移除我们也许已经写过的代码,如果我还是打算写那些代码的话,我就会发现我对它的使用都趋向于了同一个目的。
  因而,不分主次顺序,(MVC中的)一些概念和项目经受住了时间的考验:
  视图模型(ViewModel)模式,和视图与视图模型1:1的比率。它用在我宁愿在视图模型之后能有一个以之命名的视图,而不是一个动作(action)方法,这样的地方。
  展示/编辑器(Display/Editor)模板帮助。尽管我已经不再使用MVC内建的模型了--它们没有足够的灵活性。我将转而更加注重使用它们的细节。
  轻薄便利的控制器。我们可以毫无顾忌、不留情面的进行重构。这不仅仅只是用复制粘贴来重复的技能——这也是模式/概念的重复。
  没有奇特的事情。任何地方都是这样。没有字符串会引用那些“实际上”代表一个控制器/动作/属性/任何东西的类型。我们从来自MVC的适当的方式获得了90%,而其余的来自对MVC的期望(基于表达式的URL生成,包括参数的计算)。
  验证你的编辑模型(edit model)——而不是你的域模型(domain model)。除非你的app就是CRUD(增删改查),使用编辑模型表现行动(activity)/操作(operation)/命令(command),并且为那些东西附着上验证,就会是一个很大的优势。我们现在就在为那个而使用FluentValidation了——在未来还会有更多的期待。
  智能的HTML生成。使用元数据(metadata)——不是奇怪的模型元数据(Model Metadata),而就是元数据来生成HTML。测试验证属性的存在,从属性获得值,还有使用这些值来展示一个jquery面板。关于那些的更多东西很快就会到来。
  通过查询和命令来使用建模进行垂直切片测试。我并不总是一直走UI这一条老套路,但是通过模型命令和明确的查询,我们能够将行为隔离到问题的真正攸关之处,并且不必为ActionResult担心了,在我们的测试中,情况也与此类似。
  子动作(Child action)是我们的朋友。不要把一个单一的模式弄得太过零乱,也不要使用基于字典的视图数据(ViewData)访问等等。不要通过一个动作过滤器(action filter)来修改ViewData,使用子动作吧。如果你使用一种动作过滤器/ViewData方法,你基本上就放弃了自动缓存的能力。
  从元数据生成模板。FubuMVC关于此有一个很棒的示例——使用模型元数据去生成JS模板。如果你是在手动修改CSS的class属性(class="datepiker"),你就是在做某些错误的事情。不要让我认为你必须将信息放到元数据中,使用它吧!
  AutoMapper(自动映射)——我们仍然在很广泛的使用它。一开始我们为简单的场景使用反向映射(现在这个在盒子之外已经有了一些支持)。我们所没有做的是忽视了另外一方面SQL所吐出的一些东西。AutoMapper和懒加载(lazy loading)能够成为一种危险的组合——但老实说,除了使用它别无他法。
  还有一些东西没有经受住时间的考验:
  子控制器(Subcontroller),还有更小众的便携式领域。不坏的创意,但后面跟着来了更好的解决方案(子动作和NuGet)。
  动作结果中的自定义管道(Customizing pipeline)。我们有一个真的真的很需要FubuMVC行为管道(behavior pipeline)概念的项目。局限实际上出现在ActionResult的ExecuteResult方法上面。它本来应该是简单的。我们切换到到了一个调节模式(mediator pattern),跟着我们的生活就得到改善了。
  考验数据库的模型绑定。你的控制器动作携带一个域对象(domain object),从传入的GUID自动绑定。这不是诸如彼类可组合、可定制的。相反,使用你现有的工具带(toolbelt),查询对象能工作的更好,且表现得很漂亮。
  这是一个从少列出的短清单。我想要深入详细到一些工具选择的变化,但那将要等到接下来的若干篇文章中进行阐述。
  这里你没有看到的任何Javascript的东西——说老实话,远离了JS的4年是一段老长老长的时间。这个app不是使用重量级JS的,因此我无论如何都不算就它阐述任何东西。
  自从MVC2发布以来,在你的清单里面就你如何构建MVC应用程序有哪些改变呢?
在线咨询
  • 在线时间
  • 8:00-21:00
愈发强大亦或后退?4年后MVC何去何从-中国互联

愈发强大亦或后退?4年后MVC何去何从

    文章来源:中国互联 更新时间:2013-8-14 14:28:02
分享:
我已经有3年时间主要从事于使用NServiceBus来开发SOA消息系统,而中断了在Web应用程序方面的工作,而就在最近又回归到一个MVC项目上来了。许多东西已经发生了改变,但是也有许多东西一如从前。
  我们在MVC中尝试使用的大多数东西(强类型视图stringly-type view,输入/输出帮助 input/output helper,元数据驱动输出metadata-driven output 等等)使得它成为我围绕AutoMapper所得到的诸多疑问的核心——我们仍然要使用它么,等等这些问题。简短的回答是yes,意味深长的回答则是“看情况”。由于AutoMapper旨在移除我们也许已经写过的代码,如果我还是打算写那些代码的话,我就会发现我对它的使用都趋向于了同一个目的。
  因而,不分主次顺序,(MVC中的)一些概念和项目经受住了时间的考验:
  视图模型(ViewModel)模式,和视图与视图模型1:1的比率。它用在我宁愿在视图模型之后能有一个以之命名的视图,而不是一个动作(action)方法,这样的地方。
  展示/编辑器(Display/Editor)模板帮助。尽管我已经不再使用MVC内建的模型了--它们没有足够的灵活性。我将转而更加注重使用它们的细节。
  轻薄便利的控制器。我们可以毫无顾忌、不留情面的进行重构。这不仅仅只是用复制粘贴来重复的技能——这也是模式/概念的重复。
  没有奇特的事情。任何地方都是这样。没有字符串会引用那些“实际上”代表一个控制器/动作/属性/任何东西的类型。我们从来自MVC的适当的方式获得了90%,而其余的来自对MVC的期望(基于表达式的URL生成,包括参数的计算)。
  验证你的编辑模型(edit model)——而不是你的域模型(domain model)。除非你的app就是CRUD(增删改查),使用编辑模型表现行动(activity)/操作(operation)/命令(command),并且为那些东西附着上验证,就会是一个很大的优势。我们现在就在为那个而使用FluentValidation了——在未来还会有更多的期待。
  智能的HTML生成。使用元数据(metadata)——不是奇怪的模型元数据(Model Metadata),而就是元数据来生成HTML。测试验证属性的存在,从属性获得值,还有使用这些值来展示一个jquery面板。关于那些的更多东西很快就会到来。
  通过查询和命令来使用建模进行垂直切片测试。我并不总是一直走UI这一条老套路,但是通过模型命令和明确的查询,我们能够将行为隔离到问题的真正攸关之处,并且不必为ActionResult担心了,在我们的测试中,情况也与此类似。
  子动作(Child action)是我们的朋友。不要把一个单一的模式弄得太过零乱,也不要使用基于字典的视图数据(ViewData)访问等等。不要通过一个动作过滤器(action filter)来修改ViewData,使用子动作吧。如果你使用一种动作过滤器/ViewData方法,你基本上就放弃了自动缓存的能力。
  从元数据生成模板。FubuMVC关于此有一个很棒的示例——使用模型元数据去生成JS模板。如果你是在手动修改CSS的class属性(class="datepiker"),你就是在做某些错误的事情。不要让我认为你必须将信息放到元数据中,使用它吧!
  AutoMapper(自动映射)——我们仍然在很广泛的使用它。一开始我们为简单的场景使用反向映射(现在这个在盒子之外已经有了一些支持)。我们所没有做的是忽视了另外一方面SQL所吐出的一些东西。AutoMapper和懒加载(lazy loading)能够成为一种危险的组合——但老实说,除了使用它别无他法。
  还有一些东西没有经受住时间的考验:
  子控制器(Subcontroller),还有更小众的便携式领域。不坏的创意,但后面跟着来了更好的解决方案(子动作和NuGet)。
  动作结果中的自定义管道(Customizing pipeline)。我们有一个真的真的很需要FubuMVC行为管道(behavior pipeline)概念的项目。局限实际上出现在ActionResult的ExecuteResult方法上面。它本来应该是简单的。我们切换到到了一个调节模式(mediator pattern),跟着我们的生活就得到改善了。
  考验数据库的模型绑定。你的控制器动作携带一个域对象(domain object),从传入的GUID自动绑定。这不是诸如彼类可组合、可定制的。相反,使用你现有的工具带(toolbelt),查询对象能工作的更好,且表现得很漂亮。
  这是一个从少列出的短清单。我想要深入详细到一些工具选择的变化,但那将要等到接下来的若干篇文章中进行阐述。
  这里你没有看到的任何Javascript的东西——说老实话,远离了JS的4年是一段老长老长的时间。这个app不是使用重量级JS的,因此我无论如何都不算就它阐述任何东西。
  自从MVC2发布以来,在你的清单里面就你如何构建MVC应用程序有哪些改变呢?
在线咨询
  • 在线时间
  • 8:00-21:00