ASP.NET开发要抛弃ASP旧习和破烂[1]

使用ASP没有错只要适用够用就行了但是在用ASPNET开发网站或系统的时候应该抛弃开发ASP时形成的习惯用ASPNET的方法去开发而不是在ASPNET中用ASP的写法去做

在技术更新的进程中仍然有一些人死抱着已经过了气的东西不放也有一些人虽然进入到新的世界但仍摆脱不了陈旧的习惯我没有用陋习这个词因为我对这个词也非常反感

新技术应该有新技术的做法进入ASPNET的世界就应该把以往的习惯改正全新的进入新的世界把ASP的破烂扔掉

以下列举的都是错误的做法请不要误以为是推荐的做法而进行推广

使用Server Side Include给ASPX引入共同的页面构图

在ASPNET的机制下应使用ASCX(web user control)来实现ASCX提供了更多可控制接口并且更重要的是ASCX是一个类一个实实在在的类可以全面控制它

不使用webconfig

webconfig提供了非常丰富的配置管理接口是一个应用程序最核心的部分但是很多人的webconfig往往是空的或者就从来没有修改过

使用ResponseWrite向前端输出消息

ASPNET平台下的Response和ASP的Response有很大的不同虽然表示同一含义但用法上已经大不相同ResponseWrite的内容只会输出到页的最前端向前端输出消息的正确方法是使用PlaceHolder

使用一系列Session管理用户连接状态

这种方法在ASP里被滥用在ASPNET环境下正确的做法应该是设计一个类结构化地保存数据将对Session或者Cookie的访问封装起来

使用Session验证身份

这几乎是通病ASPNET提供了一组用于用户身份验证的API类型是forms验证或者windows验证这一点quick start有一节讲解得很清楚可是绝大部分人还是依靠给Session赋值来保持用户身份验证状态

使用ResponseRedirect重定向页

这一点在必要的时候可以使用但不可滥用事实证明滥用重定向将导致逻辑上的严重混乱这是在以页为程序单元的时候的做法使用front controller模式将使用户的操作逻辑集中起来

使用太多ASPX页

ASP环境下的程序单元只有*asp页ASPNET可不是这样还有后端的类库ASCX等等应将业务逻辑分别集中在不同的单元而不应该一项操作使用一个ASPX更多时候ASPX将做为ASCX或者custom control的容器而管理页内逻辑ASPX重用ASCX的同时ASPX也做为统一的页构图重用

在多个逻辑单元之间复制代码并修改相应逻辑

重用!重用!重用!处理此类问题的原则是不出现任何相同或相似的过程如果你用上面的方法一旦出现重大逻辑更改带来的结果将是灾难性的

害怕使用DataSet

很多人被DataSet吓坏了认为肯定影响性能但连最初的尝试都不敢他们总认为他们的产品一定重大设计上应该慎重他们往往使用ArrayList或者设计低级的类来保存集合数据进行艰难的数据倒入工作

[] []