2010-03-25 69 views
23

我知道很多人都非常喜欢ASP.NET MVC 2在第一个版本中所做的改进。我刚开始迁移我们的MVC 1项目,到目前为止,我们已经完全清理了我们在大型应用程序中遇到的子文件夹混乱。当我更深入地了解所做的所有改进和变化时,我仍然一直在想自己,如果他们在本版本中有x,那将会很好。例如,如果他们内置某种依赖注入而不必使用第三方解决方案,我会喜欢它。ASP.NET MVC 3 - 你想看什么功能?

我真正的问题是,现在ASP.NET MVC 2已经疯狂了,希望团队实现了哪些功能并希望他们将为ASP.NET MVC 3实现?

编辑

看起来像依赖注入是建立在ASP.NET MVC 3的第一个预览版!我喜欢迄今添加的功能。 ASP.NET 3 preview one is out!

+0

这应该是CW – 2010-03-26 00:39:19

回答

10

我认为MVC 3的改进不会太戏剧化,但更稳定和渐进。

ASP.NET MVC 3 Roadmap有一个快照,显示了团队在下一个版本中显然要实现的内容,其中一些要点非常有趣。

我想从该列表中我最喜欢的可能是:

  • 更多AJAX助手:这会带来更多的框架符合Web表单世界,拥有所有这些助手已经在一定程度上起作用作为一些人进入平台的障碍。
  • 更多依赖注入的东西 - 对于那些想要它,这是伟大的。:)
  • 改进的缓存支持对我来说是重大胜利。将它构建到框架中会是一个很大的好处,并可能会带来一些不错的性能节省。
  • 其他ValidationAttributes也不会错过。虽然这个设施非常适合添加它们,但它是一个常用的库,例如Email和PropertiesMustMatch等。
6

我真的希望他们能加入以下内容:

  1. 星火式条件和循环使用HTML标记属性。
  2. 更新:可见的项目属性切换视图的编译时验证。
  3. 有些事情要验证/验证我的路线是正确的。
  4. 成员资格提供商解决方案使用int而不是Guid进行标识,并允许将配置文件字段映射到自定义表格,而不是通用但缓慢的默认值。
  5. 基于λ-helper来回避(目前在MvcFutures)魔法串
  6. T4MVC模板自动生成强类型的辅助
  7. 项目向导或模板,使模板已经是设置了国际奥委会和类似的担忧,最好用选择对话框来选择用于IoC,单元测试等的框架。
  8. 其他属性(过滤器和验证)。

嗯,这是所有我能想到的,现在:)

+0

1.您可以将Spark视图引擎替换为您的某些视图,并且它将与传统的ASP.NET MVC视图引擎视图并行运行。 – 2010-03-25 19:29:31

+1

2.如果你这样做,你会放弃一定程度的灵活性(在应用程序仍在运行时即时更改视图的功能)。你的观点真的太复杂了,需要编译时验证吗? – 2010-03-25 19:30:58

+1

7.这将是非常好的。 – 2010-03-25 19:31:56

4

工具(T4模板)创建起订量为对象的单元测试将是非常酷。对框架中的某些对象进行测试是不必要的复杂,并且有能力对其中的一些代码进行编码会非常有益。

+0

从我这里+1。 – 2010-03-25 19:38:50

+0

++“不必要的复杂” – redsquare 2010-05-04 22:10:28

4

我想:

模具

  • 使用AJAX的备选列表视图例如使用jqGrid(实现排序,分页,搜索)
  • 对CRUD页面的增强检测实体框架类的实体关系,并使用基于字段类型的另一组组件。就像动态数据一样:)
+1

+ +1更好的CRUD工具。 – 2010-04-21 22:57:41

3

由于ASP.net MVC 3将仅限于.NET 4,我希望看到一些有关异步控制器和所有其他新的异步/多线程函数的东西.net 4带来的。

1

我想帮助自动脚手架索引视图。也许像IndexDisplay(),IndexDisplayFor()IndexDisplayForModel()

2

我希望看到的内置支持对于像IronRuby的

+0

+1支持Ruby :) – ashes999 2010-09-07 17:34:18

1

我想模板自动生成好友班在任何给定的模型。

9

我想完整删除所有魔法字符串。

0

更多的控件和帮助程序会非常好,特别是(ajax)网格。

+2

我讨厌单词“控制”,它只是让我想起像viewstate,回发和我在工作中做的事情现在:( – Jarek 2010-07-27 16:11:40

1

我也使用简单的功能,像大多数事情没有帮手,如html-helper我在asp.net MVC 3开发的东西是未来学习MVC 3的更好方法。

1

的两件事情,我想看到的大部分都是简单的看法依赖注入,过滤器等,以及(我知道这是据推测在Razor视图引擎的方式)是能够独立于ASP.Net管道(可能包括doctype验证和/或某种类型的JavaScript编译/验证)来测试我的视图。

这里有一些其他的想法:

  • 这将是很好能够打包UI组件(视图,模板,视图模型等),在多个项目中重复使用。我猜想目前这种情况有可能发生,但我只是不需要它就能够自己搞清楚。
  • controllerless actions的想法很吸引我,特别是从SRP的角度来看。
  • 更好地支持Post-Redirect-Get(P/R/G)模式......它似乎应该有对这个非常重要模式的内在支持。
2

我希望看到一种处理路由的新方法,以便更容易地开发REST服务。目前我有这样的路线:

context.MapRoute(null, 
       "api/posts", 
       new { controller = "Post", action = "Get" }, 
       new { httpConstraint = new HttpMethodConstraint("GET") }); 


context.MapRoute(null, 
       "api/posts", 
       new { controller = "Post", action = "Insert" }, 
       new { httpConstraint = new HttpMethodConstraint("POST") }); 


context.MapRoute(null, 
       "api/posts/{id}", 
       new { controller = "Post", action = "Update" }, 
       new { httpConstraint = new HttpMethodConstraint("PUT") }); 


context.MapRoute(null, 
       "api/posts/{id}", 
       new { controller = "Post", action = "Delete" }, 
       new { httpConstraint = new HttpMethodConstraint("DELETE") }); 

对于使用ASP.NET MVC的新人来说,创建匿名对象来处理路由是非常不直观的。我希望看到它修改为这样的(因为我们使用C#4.0):

context.MapRoute("api/posts", 
       controller: "Post", 
       action: "Get", 
       httpMethodConstraint: HttpMethodConstraint.GET 
       ); 

context.MapRoute("api/posts", 
       controller: "Post", 
       action: "Insert", 
       httpMethodConstraint: HttpMethodConstraint.POST 
       ); 

context.MapRoute("api/posts/{id}", 
       controller: "Post", 
       action: "Update", 
       httpMethodConstraint: HttpMethodConstraint.PUT 
       ); 

context.MapRoute("api/posts/{id}", 
       controller: "Post", 
       action: "Delete", 
       httpMethodConstraint: HttpMethodConstraint.DELETE 
       ); 

这将使它更容易被发现。