对ASP.Net网站架构设计的思考
转：http://www.cnblogs.com/kumaws/articles/web_architecture.html
相对于不同的需求，网站的大小，开发复杂度，成本，网站的架构也分许多种。
大多数小型网站，需求较为简单，安全性要求不高，开发时间短。一般这样的网站，还会有一个与数据库之间的交互。用Asp.Net中提供的控件，完全可以满足开发的要求。一般的架构如下图所示：
表示层通过数据源控件如SqlDataSource+数据控件如GridView就可以直接与数据库之间进行CRUD(CRUD是指在做计算处理时的增加、查询（重新得到数据）、更新和删除几个单词的首字母简写。主要被用在描述软件系统中数据库或者持久层的基本操作功能)操作，优点是简单，快捷。但缺点是不够灵活，对稍复杂的业务无法满足需求，而且所有数据操作都写在页面中，不但影响传输速度，也不够安全。
于是一些操作可以用ADO.Net+DataSet/DataReader完成，可将这些数据访问的代码写在App_Code或后台代码中，当数据访问写在一个类里时，就可以用ObjectDataSource控件引用这些方法，并且这个控件接收各种类型的参数，符合OO的思路。同时也可以手写操作DataSet数据表，DataSet相当于存储在内存中的数据库，内部含有DataTable二维表，根据数据写入的表名与字段名进行操作。DataSet有其优势所在，我们可以像对待数据库一样对它进行操作，而且类型化后的DataSet也能获得智能感知，排序，过滤的功能，并且可以对它进行序列化，这些特性使它在基于桌面的智能客户端应用程序大有作为。但是相对于Web应用程序来说，它还是有很大的局限性的：由于它是驻留在内存中的小型数据库，所以需要一定的系统开销，若只需要传递一行数据，仍需要创建与传递一个完整的DataSet/DataTable；数据表现形式很差，不够清晰友好；并且要添加自定义的业务验证逻辑非常困难。所以，下文将要出现的实体类更好的解决了DataSet的不足之处。
上述的这种架构设计无法应对需求的变化，耦合性过强，复用性差，无法多人同时开发。于是出现了经典的三层：数据访问层，逻辑层，表示层。PetShop就是这样的架构：
最大的变化是采用实体类替代DataSet，这个实体类基本上是与数据库表字段一一对应的关系，也会根据业务需求进行增添属性，这就做到了简单的数据持久化，而且表现形式明了，可以用智能感知，加强了OO，占用较少的内存。数据访问层只用ADO.NET与数据库间进行CRUD操作，返回了数据实体或泛型集合。逻辑层写一些业务逻辑需求的方法（不
相关文档：
源贴地址：http://www.cnblogs.com/yanyangtian/archive/2009/05/07/1451705.html
前言：异常的处理在项目开发中是很有必要的，异常的处理不仅仅只是try..catch..finally就完事了的。异常处理绝对可以称开发中的重要组成部分。必须正确的面对异� ......
asp.net 图片数据库存储详解（例子完整版）
asp.net 图片数据库存储详解（例子完整版）
按照以下的程序代码，经过本人在vs2005上的测试，修改实际可以运行的代码如下：
6个文件
是在一个发布根目录下的test文件夹中测试通过的。
SQL脚本如下：
CREATE TABLE [dbo].[image] (
[image_id] [bigint] IDENTITY ......
<%@ Page Language="C#" %>
<%@ Import Namespace="System.IO" %>
<%@ Import Namespace ="System.Text" %>
<%@ Import Namespace="System.Data" %>
<%
for (int i = 0; i <= 10; i++)
......
启动页面缓存，代码如下：
<%OutputCache Duration="60" VaryByParam="*"%>
说明：
Duration必需属性。页面被缓存旱，以秒为单位，且必须是整数。
Location 指定应输出进行缓存的位置。参数是以下选项之一：Any,Client,Downstream,None,Server,ServerAndClient
VaryByParam 必需属性。Request中变量 ......
