AbstractRecord这个名字不是很好,因为我不是太喜欢AEIOU开头的名词.
所以我选择了一个在google上,记录很少的名字,作为这个数据库访问框架的名字:RuntimeEntity
这个框架远在8月份就已经完成了一大半.然后就停止了.因为这段时间无论是工作还是生活,都有更加重要的事情要做.
这个星期将完成那些重要的事情,我会用业余的时间,整理一下RuntimeEntity,然后发布一个预览版本.
这次写BLOG,完全是受微软ASP.NET MVC的刺激.
微软的新的MVC框架, 似乎抛弃了ASP.NET控件,抛弃了ASP.NET AJAX.
回归到纯粹Render HTML的地步.我完全无法理解微软的这个做法.
当然,在那个MVC中,程序员仍然可以用XmlHttpRequest,或者其他封装好的框架去进行AJAX,
但是ASP.NET AJAX呢?没有回发,这不止否认了ASP.NET AJAX,甚至还否认了ASP.NET本身.
微软这么大的公司,难道就没有一条兼容控件和ASP.NET AJAX的做法吗?
甚至沦落到被人骂是抄袭也在所不惜? 新的MVC框架出来了对ASP.NET又有什么意义?
为了变相承认,ASP.NET的控件模式已经不适合WEB的发展了?
请大家宽恕我对MS这么严厉的指控. 我的目的纯粹是想突出我的MVC框架的特色 : 支持控件的模板引擎．
其实当初, 我做的不是MVC, 而只是需要实现一个模板引擎, 用于把视图分离出来, 方便美工.
和网上的其他模板引擎是类似的, 利用PropertyBag和后期绑定, 把内容显示出来.
不同的地方只是语法方面很针对美工的编程水平, 做到条件和循环语句非常简单和适合WYSIWYG.
但是我把我的设计推荐给老板时, 一下就被否决了 : ASP.NET控件怎么办 ?
是的. 如果一个新的东西, 抛弃了太多成熟的技术, 那么固然这个新东西的设计可以更加自由.
但是这个新的东西, 能让人接受吗? 如果微软做一个, 那么依然会有很多人追捧. 再难也会有人接受.
但是像我这样微不足道的人, 要推广自己的技术, 就不是那么简单了.
就像MS内某位语言大师说的一样, DotNet在设计的时候, 为了兼容老的程序, 为了和不同程序之间的整合,
提供了很多"救生圈". DotNet的Interop就是一个很好的例子.
当我做RuntimeEntity的时候,提供了SQL语句的支持,就有人质疑了.
要分清楚的是,搞科研和搞工程是2回事.
现在我要做的东西,一定要是一种过渡的方案,既提供新的功能,又要和老功能兼容.
综上,我对我的模板引擎进行了革新. 让它支持ASP.NET的Control,Postback和AJAX.
其实其中的原理, 是非常简单的. 换个说法, 如果把这个引擎,说成是 "Layout", 我想会更加容易让人理解.
看看传统的ASP.NET页面 :
Test.aspx:
<table>
<tr><td>Username:</td><td><asp:TextBox runat=server ID=Username></td></tr>
<tr><td>Password:</td><td><asp:TextBox runat=server ID=Password></td></tr>
<tr><td> </td><td><asp:Button runat=server ID="LoginBtn" Text="Login"></td></tr>
</table>
新的Layout方案:
Test.aspx:
<asp:TextBox runat=server ID=Username>
<asp:TextBox runat=server ID=Password>
<asp:Button runat=server ID="LoginBtn" Text="Login">
Test.view.html:
<table>
<tr><td>Username:</td><td>{#render Username}</td></tr>
<tr><td>Password:</td><td>{#render Password}</td></tr>
<tr><td> </td><td>{#render LoginBtn}</td></tr>
</table>
新的方案把一个ASPX文件, 分割出另外一个html,用于装载Layout.
可以看到的是, 新的Test.aspx本身,已经完全没有排版了.
里面纯粹就是放置大量程序用到的控件.
而在Test.view.html,则定义了这个页面的布局.
把控件Render到Template中,就是这个MVC方案兼容ASP.NET的核心思想.
做到这一步,这个MVC框架就和其他的纯粹生成HTML的框架完全不同了.
1. 如何支持MasterPage?
Test.view.html的输出过程是这样的:
Page.Render -> MasterPage.Render -> MVC.Render -> 整合Test.view.html+控件
也就是说,这个模板的输出目标, 不是Response, 而是控件Render过程中的一个部分.
这个部分的内容被MasterPage包围着, 所以能很方便地应用上MasterPage.
2. 如何做到回发?
回发和回发后调用控件的事件,是ASP.NET最重要的思想. 也是我不能离开ASP.NET的原因.
其他的所谓[ControllerAction],都不会比这个方便.因为ViewState能传递很多东西,而QueryString不能.
就如MasterPage的流程一样,控件被Render出去后,是和ASP.NET的回发机制兼容的.
当页面回发时,ASP.NET的其他基础流程依然能正常运作.
换个角度来说,这个MVC框架处理的只是Render的过程,改变了控件在浏览器上的位置.
这完全不会对ASP.NET的页面生命期造成任何影响.
3. 如何支持ASP.NET AJAX?
ASP.NET AJAX不愧是一种优秀的局部SmartNaviagtion方案.
它让程序员不需要花精力到DHTML中就能实现界面的局部刷新.
它的实现的机制,是通过拦截Page的Render过程,提取需要刷新的内容来返回给客户端.
这样一来,它就和我的MVC冲突了 : 2个都尝试拦截Render过程的东西, 又怎能放在一起工作 ?
这个MVC能支持AJAX的原因是, MVC拦截的不是Page,而只是内部一个控件的Render过程.
过程是 : AJAX-Page.Render -> Form.Render -> UpdatePanel.Render -> MVC.Render
可以看到的是, MVC.Render的过程, 是被包在UpdatePanel的Render里.
所以MVC生成的内容, 能够通过AJAX发送到客户端, 更新客户端的HTML.
---
其实这帖与其说是介绍帖,还不如说是技术研究帖.
希望能给各template的开发者一个新的思路.
打印 | 张贴于 2007-10-11 14:04:00 | Tag:AspNet
留言反馈
微软对于WEB的理解,确实还处于朦胧状态
所以才导致了现在那么多模棱两可的问题
一方面因为牵制微软的东西太多了,另一方面也许是考虑开发人员的接受能力
但是他似乎把大家的需求想简单了
我们不仅需要一种解决方案,还需要达到一种精神高度
一种对于WEB的透彻理解,海阔天空的理解
那才是我们想要的
再看看微软现在的WEB,看着就闷
最近在考虑一个权限系统
在UI权限控制的时候,想到了拦截Render,就google到了这里
呵呵
应该说在典型的InputController(Flower, POEAA)式MVC中. InputController并非实现MVC的唯一方式. 不过无论InputController还是基于WebForm式的MVC, 都无法解决View上的问题.
这种MVC, 无论RoR/MonoRail/ASP.NET MVC还是php上的类似结构所宣扬的实现方式, 大言不惭的说, 只适合10年前那种根本不使用客户端脚本的Web开发.
浏览器端应该用脚本做一个控制器, 实现典型的MVC的主动式监听. 唯一要克服的问题是, 当网页被当做一个文档而不是一个视图的时候, 如何表达机器可读的信息. 比如如何生成搜索引擎可见的文档. 做好这个工作的同时也就顺便支持了屏蔽JS的Browser. 这才是服务器端控制器应该做好的工作.
到底谁是视图, 是渲染出来的HTML文档本身, 还是浏览器上给用户呈现的界面. 不要简单的说他们是一体的, 如果这么下去, 永远也抓不到要害. 大言不惭的做个预测: 一旦世界上某个角落, 有一个程序员找到了一种更合适的视角去看待这种问题, 现在这种InputController式的MVC, 得倒一大片. 而WebForm则会通过新视角得到进化.
对于Web模型, 微软确实还是糊里糊涂, 毕竟提供框架的公司不同于Google这样的使用者, 怎么设计都行. 不过整个世界都是糊里糊涂的, 也不是微软的问题. 就等那个聪明人浮出水面了...
很明显，微软不可能摒弃ASP.NET的webform模型的，在某些情形下，webform模型更适用些，在其他情形下，MVC将更适用些。
MVC的好处在于提供了M,V,C间的松耦合性，非常容易测试，而且Controller可以根据情形render任何View，View只用来单纯地显示内容。
所谓的不支持Postback,不是不支持以POST方法提交表单，数据只能通过QueryString来传递，而是指不支持现有的在页面里按钮点击事件，下拉框改变选项后自动触发事件这样的处理方式。因为这样的方式，导致控制来自页面，以至View和其他的东西耦合太强。在典型的MVC中，QueryString只是决定了应该由哪个Controller，哪个方法来处理当前请求。
在MVC模型中，Controller是第一个处理请求的，Page的ProcessRequestMain方法没有被执行。
但如果真的又想用Controller来做调度，又想用ViewState来保留页面状态，我想也许可以有办法解决的，譬如
class MyController : IController
{
[ControllerAction]
public void Edit()
{
//作些处理，更新Model，。。。。
if (!FormHelper.IsPostBack)
{
FormHelper.RenderOldStyleASPNetView("SomeView.ascx"， ViewDataFromModel);
//在上面的方法里，没人能阻止你把你的页面状态写到<input type="hidden" name="__VIEWSTATE"里面去
}
else if (SomeValidationFailed)
{
FormHelper.RenderOldStyleASPNetViewWithViewState("SomeView.ascx",FormHelper.ViewState);
}
}
...
}
等到CTP版本出来，向微软提供反馈，也许他们可以提供这样现成的Hook来满足你的要求
为了让更多的人选择asp.net，让asp.net作为一个更好的平台也有错？
所以我不认为这是个坏消息，当然你的心情可以理解，某些人不喜欢JSF也正是因为这种类asp.net的解决方案会让人不习惯，我倒是很希望微软的这次mvc框架能给人带来真正让人激动的值得java去"抄袭"和"模仿"的新东西:)
"不支持Postback"也是听说回来的,而我觉得这个是真实的.
因为 "不支持XXX" 通常都是官方自己的声明, 其他人不清楚的话是不会说这种话的.
所以发这个文章,比较针对Postback的意义.
不支持Postback, 后果实在太严重.
只是希望MS能找到一个兼容的方案.
到目前为止，我对于这个MVC架构了解还不是非常多，所以也不敢说什么。
不过我的建议是：如果是对于现有ASP.NET技术比较熟悉的话，可以继续使用现有技术。如果对架构灵活性有非常高的要求的情况下，可以使用这套新的Framework。相当于提供新的选择吧。