对于ASP.NET与J2EE框架的一点想法
2004-08-27 20:01 FantasySoft 阅读(3291) 评论(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的开发当中也能有这样的页面事件处理函数啊！或许这只是一个无稽的想法，但是寻找开发中的平衡点，不正是我们要做的吗？
