对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操作，返回了数据实体或泛型集合。逻辑层写一些业务逻辑需求的方法（不
相关文档：
切记，切记 DateTime.Now.Date.ToString("yyyy年MM月dd日"); //MM 要大写，否则会是00,不是真实的月份 private void getDate()
{
date.Text = DateTime.Now.Date.ToString("yyyy年MM月dd日"); //这个随意的：yyyy-MM-dd 也可以
string Temp="";
switch (DateTime.Now.DayOfWeek)
{
case DayO ......
asp.net获取客户端的MAC地址〔只适用于局域网〕
[转]http://www.cnblogs.com/scgw/archive/2008/08/01/1213951.html
近日在做一个投票系统中有这样一个需求：为了防止恶意拉票或刷票，需要通过远程客户端的IP地址
来获取客户端网卡的MAC地址。晚上找了很多资料，终于有点收获。
如何取得网� ......
首先要添加
using System.Data;
using System.Data.SqlClient;
接下来：
SqlConnection conn = new SqlConnection("server=QLPC\\SQL2005;uid=sa;pwd=（你的密码）;database=（你的数据表）"); &n ......
启动页面缓存，代码如下：
<%OutputCache Duration="60" VaryByParam="*"%>
说明：
Duration必需属性。页面被缓存旱，以秒为单位，且必须是整数。
Location 指定应输出进行缓存的位置。参数是以下选项之一：Any,Client,Downstream,None,Server,ServerAndClient
VaryByParam 必需属性。Request中变量 ......
