razor真的还不错

乱码

放假这几天晚上趁孩子睡觉，由回去revisit了一下aspx low level的page life cycle，觉得真的好罗索阿(不过很多灵活性也就体现在这些细节上了)，怪不得ms在mvc3中主推razor呢，aspx看来今后也就是基本上停留在webform和mvc1/2了。

http://blog.andrewnurse.net/2010 ... ursivePingPong.aspx

这哥们是负责写razor的parser的，有几个blog有关inside razor的，写的很不错，建议感兴趣的同学读一下，注意最下面的相关阅读。

典

不是的啦，此 ASPX 非彼ASPX
在MVC3下 ASPX = Razor （从Lifecycle之类的来讲），都是一个由Action控制的View

唯一不同的是@ 代替 %(两个)， 当然具体的语法上有细微的差别，但毕竟是很小的部分

之所以推Razor是因为开放社区某有名的Framework用@,aspx继承了asp继续用<%%>

如果已经习惯用<%就用aspx,
否则就用Razor,或者根据公司的规定来，
用RAZOR 或者 ASPX没有优劣好坏之分

[ 本帖最后由 典 于 2011-1-1 19:15 编辑 ]

乱码

原帖由 典 于 2011-1-1 20:09 发表
不是的啦，此 ASPX 非彼ASPX
在MVC3下 ASPX = Razor （从Lifecycle之类的来讲），都是一个由Action控制的View

唯一不同的是@ 代替 %(两个)， 当然具体的语法上有细微的差别，但毕竟是很小的部分

之所以推Razor是因为开放社区某 ...

如果用aspx做view，还是要走它自己原来的life cycle，即使没有code behind，但razor应该没有life cycle，可以这样理解么？

kr2000

你们放假还这么勤奋

乱码

原帖由 kr2000 于 2011-1-1 22:12 发表
你们放假还这么勤奋

我在看原来的东西，这两天warm up一下，等过完年找工作呢

典

MVC 下的ASPX,已经没有Postback, 没有Viewstate,没有Event,
当然也就没有Lifecycle鸟，代码的写法又和ASP时代一样了
就是个View
Razor的View Engine当然也有点点好处，可能效率高点？但不是什么大问题

乱码

原帖由 典 于 2011-1-1 22:39 发表
MVC 下的ASPX,已经没有Postback, 没有Viewstate,没有Event,
当然也就没有Lifecycle鸟，代码的写法又和ASP时代一样了
就是个View
Razor的View Engine当然也有点点好处，可能效率高点？但不是什么大问题 ...

你可能没明白我什么意思，即使在mvc下，我们也有写code behind的能力，来真对life cycle写code，但只是不推荐这么做，很多page life cycle的是aspx自己的method触发的，而不仅仅是event，就是说如果用aspx这个engine，这些method一定会执行，no matter what，而event handler如果没有subscribe，就为空，不用去trigger它。

http://msdn.microsoft.com/en-us/library/ms178472.aspx

我知道有前期mvc的商业产品，还是在误用aspx life cycle写东西，仍然有viewstate，根webform差别也就是在model/TTD上.

我的理解，razor比较单一，它通过parser弄出来的东西就是大框架是c#的data flow statement,夹杂着htmlwriter写出来的markup，跟aspx markup应该没什么不同。但它肯定是没有page life cycle的。

典

这样说吧，
当建立项目的时候，就要决定是哪种项目MVC ? Webform?
如果使用Webform, 其中的Aspx Page 就会有LifeCycle
如果使用MVC, 其中的View ASPX就没有了Lifecycle

当然，在MVC下，依然可以使用传统的Webform ASPX （非View也）

乱码

原帖由 典 于 2011-1-1 23:35 发表
这样说吧，
当建立项目的时候，就要决定是哪种项目MVC ? Webform?
如果使用Webform, 其中的Aspx Page 就会有LifeCycle
如果使用MVC, 其中的View ASPX就没有了Lifecycle

当然，在MVC下，依然可以使用传统的Webform ASPX （非Vi ...

我个人的理解是aspx life cycle 不取决于project，也不取决于是否有code behind.

mvc 1.0(beta?)mvc project当时都给生成code behind让developer写code的，后来这东西没有了，只是aspx file，我觉得它从engine上没做过多的改变，如果想手动加一个aspx的partial class来做code behind，应该没什么问题，不过我没做试验，不是很确定。

Roman

恩，我也在考虑买个雷蛇鼠标玩游戏。

乱码

原帖由 Roman 于 2011-1-2 03:00 发表
恩，我也在考虑买个雷蛇鼠标玩游戏。

我玩过你说的这个，上面键太多，不知道摁哪个

乱码

得到确认。

http://forums.asp.net/t/1638437. ... ge+life+cycle+as+it

典

也试了一下MVC3，确实如此，如果view 里边有@page 的话 , aspx支持原来的Lifecycle，看来还是用得太少。
Razor的view 里边缺省就没有@page directory （能手工加吗？）,应该就没有什么Lifecycle了....

话说回来，企业级的应用程序好像没有什么理由非要用哪个，似乎使用任何一个都没有优劣之分，看不出优缺点，也许到Razor 2.0就可以有优点了

乱码

原帖由 典 于 2011-1-4 03:32 发表
也试了一下MVC3，确实如此，如果view 里边有@page 的话 , aspx支持原来的Lifecycle，看来还是用得太少。
Razor的view 里边缺省就没有@page directory （能手工加吗？）,应该就没有什么Lifecycle了....

话说回来，企业级的应用程序 ...

Razor应该没有什么page life cycle，aspx中那些life cycle events主要是给control用的，它的initialization/state recovery/modification/data binding/rendering/disposal... razor的任务主要是rendering，应该也不需要这些.

IsDonIsGood

本着no question is stupid的精神,有个问题，如果太低级莫怪.
MVC给我的感觉是又把logic code 和html 代码混在一起，回到了asp时代，当然jquery的应用和MVC的分层结构会让MVC比asp时代的代码更具可读性。但是依然会觉的代码不容易看懂，可能是比较习惯于webform的模式。这样做的好处究竟在那里？

乱码

原帖由 IsDonIsGood 于 2011-1-4 10:03 发表
本着no question is stupid的精神,有个问题，如果太低级莫怪.
MVC给我的感觉是又把logic code 和html 代码混在一起，回到了asp时代，当然jquery的应用和MVC的分层结构会让MVC比asp时代的代码更具可读性。但是依然会觉的代 ...

I feel the same way.

不过目前也想不出更好的主意来如何mix markup and c# code,毕竟view是用来render的，次序很重要。不过没有“真正的”logic在里面，只是用logic来control html rendering.

code behind/htlm 分离可能以后会有吧，但也不是那么容易就能实现的。

Dan.and.Andy

原帖由 IsDonIsGood 于 2011-1-4 10:03 发表
本着no question is stupid的精神,有个问题，如果太低级莫怪.
MVC给我的感觉是又把logic code 和html 代码混在一起，回到了asp时代，当然jquery的应用和MVC的分层结构会让MVC比asp时代的代码更具可读性。但是依然会觉的代 ...

没研究过的瞎说一句, MVC 就是 light weight, 瞄准的就是PHP, 把原来从asp --> asp.net 的人拉拢住, 网站的framework.

web form 建网站实在是太冗余了, render的乱七八糟的 html 不容易读。.net程序员往往不是好的美工和 web designer，大网站 front-end 往往也是一个大的团队，挣的只比.net 程序员多，不比程序员少。web form 应该是与像sharepoint 这样的平台挂钩，专注于企业级应用，大平台上的工具。

未来的趋势也许应该纯粹的html/css RIA应用，mvc顺应了潮流，也只能说是一种回归.

瞎说的... ...

jl162401

高人指导一下,这都是啥东东阿?

Dan.and.Andy

原帖由 乱码 于 2011-1-4 11:24 发表


I feel the same way.

不过目前也想不出更好的主意来如何mix markup and c# code,毕竟view是用来render的，次序很重要。不过没有“真正的”logic在里面，只是用logic来control html rendering.

code behind/h ...

没用过问一句，能不能像 php 一样在 html 中查入一些类似 bookmark 的占位标识符，然后将 code 写入code behind的文件，render的时候插入执行，从文件上看只有html和bookmark？

乱码

原帖由 Dan.and.Andy 于 2011-1-4 11:46 发表


没用过问一句，能不能像 php 一样在 html 中查入一些类似 bookmark 的占位标识符，然后将 code 写入code behind的文件，render的时候插入执行，从文件上看只有html和bookmark？ ...

placeholder是control，又回到webform了

简单应用还行，但如何做markup loop rendering的操作？比如render list of <li>

这类问题很tricky，可能我们想破头都没有好办法

乱码

原帖由 jl162401 于 2011-1-4 11:42 发表
高人指导一下,这都是啥东东阿?

http://www.asp.net/mvc

乱码

原帖由 Dan.and.Andy 于 2011-1-4 11:41 发表


没研究过的瞎说一句, MVC 就是 light weight, 瞄准的就是PHP, 把原来从asp --> asp.net 的人拉拢住, 网站的framework.

web form 建网站实在是太冗余了, render的乱七八糟的 html 不容易读。.net程序员往往不是好 ...

嗯，比较同意。

webform 当初最大的特色就是abstraction, http/html都被特意隐藏了，就连postback，如果有updatepanel，都能做的让用户毫不觉察，现在看来，有些是很对的，比如productivity，但有些是很致命的缺陷：performance，testability...

从webform设计的本身来看，挖掘的越低层，越觉得它细节的地方很优雅，如果没有mvc作比较，它的确是当今最优秀的framework之一

yajiya

跟NVelocity很像，不过既然是编译执行的。应该性能会更好一些。

showen

恩 感觉Dan.and.Andy说的比较有道理

MS的产品线很长，mvc可能真的是定位在和php的一个级别，用于建立网站，并且和前台的js frame work (jquery)能够很好的一起使用。

对于企业级应用，sharepoint估计能应付大部分的要求，剩下的需要用定制的silverlight来弥补空白。

乱码

原帖由 showen 于 2011-3-27 14:02 发表
恩 感觉Dan.and.Andy说的比较有道理

MS的产品线很长，mvc可能真的是定位在和php的一个级别，用于建立网站，并且和前台的js frame work (jquery)能够很好的一起使用。

对于企业级应用，sharepoint估计能应付大部分的要求，剩下的需要用定制的silverlight来弥补空白。

嗯，目前做mvc的人都是focus在high traffic public website，但随着这个framework影响力渐入人心，它的应用也会越来越普遍。

企业级的应用不是牺牲性能的借口，经常能见到为企业量身定制的project做到最后都无法维护，性能更不能提了。

silverlight/wpf很多.net developer都不想往这个方向作，主要是应用太少，前景很有局限，不利于以后职业发展。

这两天在家debug mvp,这个framework也很有意思，

1.它比较轻，kick in的时机不是http module那个level的,而是control level的（开始没改web.config还是让我很吃惊的，对framework来说很难置信）.
2.没有url rounting,得自己做，不过也不难，.net 3.5 routing dll已经有了。
3.没有很明确的反对用server control，但也不鼓励，最好还是用html tag.
4.用到page/user control的live cycle events,这个严格来说性能会受点影响，不过也是没有办法的事.
5.侧重webform的testability.

总的来说，如果不想一下换到mvc,mvp还算是一个好的选择，不过这种中间级的东西生命力都不行，出到现在1.0之后很少有正式的support,用户也少，估计再过1/2年，它就完全完蛋了.

不过它的很多思路还是值得后人借鉴的, 可惜生不逢时，跟mvc撞上了，如果提前两年，这个framework肯定火了。

[ 本帖最后由 乱码 于 2011-3-27 14:53 编辑 ]