从ASP过渡到ASP.net遗留的二十大积习
在技术更新的进程中, 仍然有一些人死抱着已经过了气的东西不放. 也有一些人虽然进入到新的世界, 但仍摆脱不了陈旧的习惯. 我没有用”陋习”这个词, 因为我对这个词也非常反感.
新技术应该有新技术的做法, 进入ASP.NET的世界, 就应该把以往的习惯改正, 全新的进入新的世界.
以下列举的都是错误的做法, 请不要误以为是推荐的做法而进行推广:
1. 使用server side include给ASPX引入共同的页面构图.
在ASP.NET的机制下, 应使用ASCX(web user control)来实现. ASCX提供了更多可控制接口. 并且更重要的是, ASCX是一个类. 一个实实在在的类. 可以全面控制它.
2.不使用web.config
web.config提供了非常丰富的配置管理接口. 是一个应用程序最核心的部分. 但是很多人的web.config往往是空的. 或者就从来没有修改过.
3.使用Response.Write向前端输出消息
ASP.NET平台下的Response和ASP的Response有很大的不同. 虽然表示同一含义, 但用法上已经大不相同. Response.Write的内容只会输出到页的最前端. 向前端输出消息的正确方法是使用PlaceHolder.
4.使用一系列session管理用户连接状态
这种方法在ASP里被滥用. 在ASP.NET环境下, 正确的做法应该是设计一个类. 结构化地保存数据. 将对session或者cookie的访问封装起来.
5.使用session验证身份
这几乎是通病. ASP.NET提供了一组用于用户身份验证的API. 类型是forms验证或者windows验证. 这一点quick start有一节讲解得很清楚. 可以绝大部分人还是依靠给session赋值来保持用户身份验证状态.
6.使用Response.Redirect重定向页
这一点在必要的时候可以使用. 但不可滥用. 事实证明滥用重定向将导致逻辑上的严重混乱. 这是在以页为程序单元的时候的做法. 使用front controller模式将使用户的操作逻辑集中起来]
7.使用太多ASPX页
ASP环境下的程序单元只有*.asp页, ASP.NET可不是这样, 还有后端的类库, ASCX等等. 应将业务逻辑分别集中在不同的单元, 而不应该一项操作使用一个ASPX. 更多时候ASPX将做为ASCX或者custom control的容器而管理页内逻辑. ASPX重用ASCX的同时, ASPX也做为统一的页构图重用.
8.在多个逻辑单元之间复制代码并修改相应逻辑
重用. 重用. 重用. 处理此类问题的原则是不出现任何相同或相似的过程. 如果你用上面的方法, 一旦出现重大逻辑更改, 带来的结果将是灾难性的.
9.害怕使用DataSet.
很多人被DataSet吓坏了. 认为”肯定”影响性能. 但连最初的尝试都不敢. 他们总认为他们的产品一定重大, 设计上应该”慎重”. 他们往往使用ArrayList或者设计低级的类来保存集合数据. 进行艰难的数据倒入工作.
------解决方案--------------------说得好!!
------解决方案--------------------学习
------解决方案--------------------我有3个:
3.使用Response.Write向前端输出消息
6.使用Response.Redirect重定向页
13.自己写的东西最靠得住
自己写的东西最靠得住,呵呵,我不认为这个不对
即使用别人的,我也要修改一下他的源码,至少要看懂(没有就反编译一下)
------解决方案--------------------不是从ASP转来的, 直接就学ASP.NET, 其它WEB开发也从未接触过, 但下面的习惯我都有.
5.使用session验证身份
// 不用这个我用什么, 其实我不懂用其它对象验证身份
6.使用Response.Redirect重定向页
// 这个有什么问题吗?! 不用这个还用什么, 难道用JS脚本的window.open()?!
10.对“性能”过多注意.
// 其实我是对ASP.NET了解不深, 还不太了解其资源管理机制
15.从来不作继承或派生
// 其实我是不太熟悉继承和派生
18.使用DreamWeaver“画“ASPX
// 对于这个很绝对不同意, 因为VS的HTML页面编辑功能太弱, 很多属性不知道怎么改, 只好在
// DW和FP里做好, 然后COPY到VS
21.零事件
// 可能我平时只做点小东西吧, 这高级还用不到, 再就是不太懂