1. 使用server side include给ASPX引入共同的页面构图.
在ASP.NET的机制下, 应使用ASCX(web user control)来实现. ASCX提供了更多可控制接口. 并且更重要的是, ASCX是一个类. 一个实实在在的类. 可以全面控制它.
2.不使用web.config
web.config提供了非常丰富的配置管理接口. 是一个应用程序最核心的部分. 但是很多人的web.config往往是空的. 或者就从来没有修改过.
web.config 主要是保留服务器的配置的和全局的信息,这个在Telligent Systems 的 forums的代码中大大的体现:
1。引入名称空间信息
2。数据访问、文件上传目录,资源文件目录等全局信息
3.使用Response.Write向前端输出消息
ASP.NET平台下的Response和ASP的Response有很大的不同. 虽然表示同一含义, 但用法上已经大不相同. Response.Write的内容只会输出到页的最前端. 向前端输出消息的正确方法是使用PlaceHolder.
~~~~~~~~~~~
这点说不上是任何技巧,熟悉
HTML的人都应该知道这样做
4.使用一系列session管理用户连接状态
这种方法在ASP里被滥用. 在ASP.NET环境下, 正确的做法应该是设计一个类. 结构化地保存数据. 将对session或者cookie的访问封装起来.
~~~~~~~~~~~~~~
意思应该是说把用户这个对象保存起来吧,这个的确应该如此
5.使用session验证身份
这几乎是通病. ASP.NET提供了一组用于用户身份验证的API. 类型是forms验证或者windows验证. 这一点quick start有一节讲解得很清楚. 可以绝大部分人还是依靠给session赋值来保持用户身份验证状态.
~~~~~~~~~~~~~~
很多人的确是这样使用,自己也有这样的毛病,应该改改
6.使用Response.Redirect重定向页
这一点在必要的时候可以使用. 但不可滥用. 事实证明滥用重定向将导致逻辑上的严重混乱. 这是在以页为程序单元的时候的做法. 使用front controller模式将使用户的操作逻辑集中起来]
~~~~~~~~~~~~~
response.redirect 只是页面跳转而已
7.使用太多ASPX页
ASP环境下的
程序单元只有*.asp页, ASP.
NET可不是这样, 还有后端的类库, ASCX等等. 应将业务逻辑分别集中在不同的单元, 而不应该一项操作使用一个ASPX. 更多时候ASPX将做为ASCX或者custom control的容器而管理页内逻辑. ASPX重用ASCX的同时, ASPX也做为统一的页构图重用.
8.在多个逻辑单元之间复制代码并修改相应逻辑
重用. 重用. 重用. 处理此类
问题的原则是不出现任何相同或相似的过程. 如果你用上面的方法, 一旦出现重大逻辑更改, 带来的结果将是灾难性的.
~~~~~~~~~~~~~~~~~~~
增加代码复用性,就应该少“复制”代码
Array.害怕使用DataSet.
很多人被DataSet吓坏了. 认为”肯定”影响性能.
但连最初的尝试都不敢. 他们总认为他们的产品一定重大,
设计上应该”慎重”. 他们往往使用ArrayList或者设计低级的类来保存集合数据. 进行艰难的数据倒入工作.
~~~~~~~~~~~~~~~~~~~~~~~
自己设置的类也是有自己的好处的,如果数据集合之后没有联系,那直接用dataTable即可。
10.对“性能”过多注意.
对ASP.NET ViewState的机制特别不满. 或者总是挖空心思迫害人家. 反倒把自己弄得很累. 如果在对付ViewState的同时多注意少连几次数据库也许更文明些.
~~~~~~~~~~~~~~~
如果开发使用人数比较少的系统,性能考虑倒不是主要,因为一般的服务器都可以伺候比较多的人数,如果性能可能成为
系统瓶颈,那就应该大大的优化,少用服务器控件
11.应用程序根目录很乱.
ASP.NET是开发项目. 不是网站. 应该把不同的资源分类放置. 例如把所有静态资源(样式表, 脚本, 图像)组织到一起. 甚至可以写一组API来管理他们. ASPX应该放在一起. ASCX应该放在一起. .*.cs呢? 应该把他们放到另外一个project里.
~~~~~~~~~~~~~
这个同意,至少数据访问层要做为单独的类库。
12.不厌其烦的写访问数