对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操作，返回了数据实体或泛型集合。逻辑层写一些业务逻辑需求的方法（不
相关文档：
我觉得这个文章不能算我的原创，因为代码也是我从别的地方找到的，而且我在网上查了，基本上都是这套代码。
通用的把数据倒进word或者excel。这里的导入excel和我之前的那篇文章中的方法是不一样的。
代码如下：
aspx页面中：
<form id="form1" runat="server">
&nbs ......
string path = "...\\Debug\\log.txt";
if (!File.Exists(path))
& ......
asp.net 图片数据库存储详解（例子完整版）
asp.net 图片数据库存储详解（例子完整版）
按照以下的程序代码，经过本人在vs2005上的测试，修改实际可以运行的代码如下：
6个文件
是在一个发布根目录下的test文件夹中测试通过的。
SQL脚本如下：
CREATE TABLE [dbo].[image] (
[image_id] [bigint] IDENTITY ......
1. 打开新的窗口并传送参数：
传送参数：
response.write("<script>window.open('*.aspx?id="+this.DropDownList1.SelectIndex+"&id1="+...+"')</script>")
接收参数：
string a = Request.QueryString("id");
string b = Request.QueryString("id1");
2.为按钮添加对话框
Button1.Attribut ......
首先要添加
using System.Data;
using System.Data.SqlClient;
接下来：
SqlConnection conn = new SqlConnection("server=QLPC\\SQL2005;uid=sa;pwd=（你的密码）;database=（你的数据表）"); &n ......
