对于ASP.NET与J2EE框架的一点想法
2004-08-27 20:01 FantasySoft 阅读(3290) 评论(5) 编辑 收藏 举报
没有用ASP.NET来开发Web Application也有一段时间了,虽然她的轮廓在我的记忆中已经开始模糊,但是她的美丽还是深深烙在我的心中,不曾磨掉。
让我再一次想念ASP.NET源于在Web Application要实现的一个功能:从数据库中筛选出一些数据,并显示出来。聪明的您或许会觉得这个功能很简单,是的,真的很简单,不管是ASP.NET还是使用JSP+Servlet来做。但是这个处理逻辑应该放在什么地方呢?
在ASP.NET中,要实现这个小小的功能,不管是使用DataGrid也好,DataList也好,或者Repeater也好,都是在Page_Load事件中将DataSource绑定去实现,而在页面上通过控件将相应的数据显示出来。我们可以看到逻辑处理是放在一个Page_Load事件中的;
而使用J2EE各种各样的框架,通常都会有一个Servlet作为request的Dispatcher,当这个Servlet接收到某种pattern的请求后(如WAF中的.do,WebWork中的则是.action),将会通过读取配置文件得到处理这个request的class,相应的逻辑处理完之后,就会将得到的结果(这个例子中,就会得到一个Collection)放到request当中,最后再由作为Dispatcher的Servlet将request推到相应的View中。而在View(将会是JSP)中通过标签库的Iterator标签获得Collection,并显示之。从以上的分析,我们也可以发现,逻辑处理是放在了处理request的class中。
综上所述,ASP.NET作为一个框架所关注的是页面本身以及页面包含的控件,从ASP.NET支持的方法就可以看出来了,如Page_Render,Page_Load, Page_Unload,OnChange,OnClick等等,却没有将Request和Response做为重要的对象来对待,这样的一个关注点使得ASP.NET的开发变得十分的简便。但是,这样的做法也并非十全十美,象Page之间的关系,在整个Application当中,是没有地方进行描述的;而J2EE框架关注的是Request,Response,Parameter这些隐含的对象,对于页面控件触发的事件则没有做相应的重视,这样的一个关注点就使得J2EE的框架在处理业务逻辑上面显得十分的灵活,因为我们细分了用户的每一个请求,而每一个请求在配置文件中都有清楚的描述,整体脉络是很清晰的。但是厚此薄彼的做法也造成了页面开发的低效并增加了开发的难度。
再次回到前文提出的那个功能,在ASP.NET当中的具体实现我就不用多说了,很简单,简单得让我眼馋。而在J2EE的框架当中,如果对数据浏览的请求是由用户主动发出的话,实现起来也是非常自然的。但是如果这些数据需要显示在首页,我该怎么办呢?我想我能做的就是在首页显示之前去定义一个.action或者.do,让用户一进入网站的时候,并不是直接去访问首页,而是访问在首页之前的.action或者.do。然后由相应的class处理完数据的查询之后,再将request分发(Dispatch)到首页去。这样是不是很麻烦呢?除此之外的办法就是在页面上写Java代码,这样也就破坏View与Control分离的原则了。这个时候,我多么希望在J2EE的开发当中也能有这样的页面事件处理函数啊!或许这只是一个无稽的想法,但是寻找开发中的平衡点,不正是我们要做的吗?
让我再一次想念ASP.NET源于在Web Application要实现的一个功能:从数据库中筛选出一些数据,并显示出来。聪明的您或许会觉得这个功能很简单,是的,真的很简单,不管是ASP.NET还是使用JSP+Servlet来做。但是这个处理逻辑应该放在什么地方呢?
在ASP.NET中,要实现这个小小的功能,不管是使用DataGrid也好,DataList也好,或者Repeater也好,都是在Page_Load事件中将DataSource绑定去实现,而在页面上通过控件将相应的数据显示出来。我们可以看到逻辑处理是放在一个Page_Load事件中的;
而使用J2EE各种各样的框架,通常都会有一个Servlet作为request的Dispatcher,当这个Servlet接收到某种pattern的请求后(如WAF中的.do,WebWork中的则是.action),将会通过读取配置文件得到处理这个request的class,相应的逻辑处理完之后,就会将得到的结果(这个例子中,就会得到一个Collection)放到request当中,最后再由作为Dispatcher的Servlet将request推到相应的View中。而在View(将会是JSP)中通过标签库的Iterator标签获得Collection,并显示之。从以上的分析,我们也可以发现,逻辑处理是放在了处理request的class中。
综上所述,ASP.NET作为一个框架所关注的是页面本身以及页面包含的控件,从ASP.NET支持的方法就可以看出来了,如Page_Render,Page_Load, Page_Unload,OnChange,OnClick等等,却没有将Request和Response做为重要的对象来对待,这样的一个关注点使得ASP.NET的开发变得十分的简便。但是,这样的做法也并非十全十美,象Page之间的关系,在整个Application当中,是没有地方进行描述的;而J2EE框架关注的是Request,Response,Parameter这些隐含的对象,对于页面控件触发的事件则没有做相应的重视,这样的一个关注点就使得J2EE的框架在处理业务逻辑上面显得十分的灵活,因为我们细分了用户的每一个请求,而每一个请求在配置文件中都有清楚的描述,整体脉络是很清晰的。但是厚此薄彼的做法也造成了页面开发的低效并增加了开发的难度。
再次回到前文提出的那个功能,在ASP.NET当中的具体实现我就不用多说了,很简单,简单得让我眼馋。而在J2EE的框架当中,如果对数据浏览的请求是由用户主动发出的话,实现起来也是非常自然的。但是如果这些数据需要显示在首页,我该怎么办呢?我想我能做的就是在首页显示之前去定义一个.action或者.do,让用户一进入网站的时候,并不是直接去访问首页,而是访问在首页之前的.action或者.do。然后由相应的class处理完数据的查询之后,再将request分发(Dispatch)到首页去。这样是不是很麻烦呢?除此之外的办法就是在页面上写Java代码,这样也就破坏View与Control分离的原则了。这个时候,我多么希望在J2EE的开发当中也能有这样的页面事件处理函数啊!或许这只是一个无稽的想法,但是寻找开发中的平衡点,不正是我们要做的吗?