catjiangyh

 
 
昵称:姜翊华
园龄:5年10个月
粉丝:0
关注:0

搜索

 
 

常用链接

  • 我的随笔
  • 我的评论
  • 我的参与
  • 最新评论
  • 我的标签

随笔档案

  • 2006年12月 (5)
  • 2006年3月 (1)

最新评论

阅读排行榜

评论排行榜

推荐排行榜


Powered by: 博客园
模板提供:沪江博客
博客园 | 首页 | 发新随笔 | 发新文章 | 联系 | 订阅订阅 | 管理

2006年12月22日

[翻译]Accessing and Updating Data in ASP.NET 2.0: Examining the Data Source Control's Events

Accessing and Updating Data in ASP.NET 2.0: Examining the Data Source Control's Events

                                                                                                                                                   Written by Scott Mitchell  
                                                                                                                                                   Translated by jiangyh

简介

ASP.NET 2.0数据控件提供了一个简单、直接的方法去访问和修改数据。Data Source Control Basics是一篇入门级的文章,这篇文章的一系列练习教给了我们如何向一个页面追加数据控件、对指定的数据源进行抽出和/或修改操作和如何绑定数据到一个web控件(例如GridView、DetailsView或FormView)上。用这种点击和选择的方式去设定访问数据的方法非常适合新手和没有经验的程序爱好者,这些向导的方式访问数据对于有经验的程序员来讲却是比较麻烦的,由于这样使程序缺少了扩展和自定义的空间。然而,ASP.NET 2.0数据控件却解决了这两方面的问题,依我看,它们不但可以快速而且简单的对数据进行配置和使用,而且通过使用数据控件生命周期中引发的大量事件,在一些特殊的情况下给程序提供了很多的灵活性。

 

SqlDataSource和SqlDataSource是两个非常通用的数据控件,它们分别提供了一个方法从任何一个数据库或者数据源去取得和修改数据。两个数据控件在selecting、inserting、updating和deleting执行前和提交后的时候都引发了一些事件。例如,SqlDataSource和ObjectDataSource控件在执行查询SQL或者调用取得数据的方法的时候就引发了Selecting事件。在数据取得完成以后又引发了selected事件。通过创建一个Selecting事件句柄,你可以检查或者表示检索的参数;在Selected事件中,可以做一些其他的事情,比如处理在执行操作中出现了异常。类似的updating、inserting和deleting操作前和后引发的事件,和select也是一样的。

 

非常清楚数据控件事件和事件的生命周期会有很多的好处。现实中很多情况都是在selecting、inserting、updating或者deleting这些执行前事件中分配和改变数据。而且,漂亮的处理数据库和数据源级别的异常,在执行后事件中是非常好的。并且,当调试的时候,执行前事件还可以提供给我们一个机会去检查检索数据用的参数是否正确。让我们开始学习吧。

 

数据控件事件模式

SqlDataSource和ObjectDataSource控件提供了一些方法去检索,更新,插入和删除数据(Select(), Insert(), Update(), and Delete()).这些方法可以通过程序来调用,但是通常的情况下是自动的被已经绑定好的数据控件调用。当SqlDataSource控件的Select()被调用的时候,他将建立一个指定的连接到数据库,然后执行SelectCommand方法,并且返回一个DataView或者DataReader(这个依赖于DataSourceMode属性的设定)。当ObjectDataSource控件的Select()方法被调用的时候,他的配置对象将被实例化,并且它指定的方法将会被调用,方法的结果将会从Select()方法返回。

 

尽管SqlDataSource和ObjectDataSource控件的Select()方法的内部有些不同,但是两个控件都是一样的事件模式。对于Select()、Insert()、Update()和Delete()这四个方法,SqlDataSource和ObjectDataSource将会引发处理前和处理后事件。一个事件执行比较优先,另一个事件随后执行。通过事件的名字可以判断是在方法执行前出发还是执行后出发。Selecting事件在取得数据前被引发,然后Select方法被执行,最后引发了Selected方法,下面的图解说明了这个模式。

                      

 

上图描述了ObjectDataSource控件的Select()方法,Insert()、Update()和Delete()方法还有SqlDataSource控件的4个方法和上面的模式一样。对于概念SqlDataSource和ObjectDataSource控件是完全一致的,但是实现的细节有些不同。

 

SqlDataSource控件的执行前事件的练习

SqlDataSource控件的执行前事件传递的是Command对象的一个引用,用来执行数据库访问,Command对象中包含了一些信息。Command对象CommandText属性包含着执行的SQL语句或者存储过程名。Command对象还包含了用于查询的参数集合。

 

如果你希望输出SELECT、INSERT、UPDATE或者DELETE 语句中的参数,你就可以适当的使用不同的执行前事件。例如,用下面的代码去构造带有一个SelectCommand对象的SqlDataSource控件。

 

SELECT 
FROM Employees
WHERE Salary > @Salary 

SqlDataSource控件的<SelectParameters>集合包含了一个参数。这个参数的指定方法有很多,可以直接声明,可以写一个不变的值或者从页面上取得一个值,或者是一个查询来的值等等。不管怎么样,你的这个参数的值都可以在Selecting事件中被检查或者修改(如果你需要的话)。(请参照Filtering Database Data with Parameters文章去获得如何使用数据控件参数)

 

对于SqlDataSource控件,你可以通过e.Command.Parameters("parameterName")代码去取得或者改变@Salary参数的值。

 

Protected Sub CategoriesDataSource_Selecting(ByVal sender As Object, ByVal e As System.Web.UI.WebControls.SqlDataSourceSelectingEventArgs) Handles CategoriesDataSource.Selecting
   
'Set parameter value through e.Command.Parameters
   e.Command.Parameters("@Salary").Value = 50000
End Sub 

请参照Change the Value of the Data Source Control's Update and Insert Parameters文章去了解更多的关于如何设置数据控件参数的信息。

 

请通过文章下面的链接去下载例子代码,其中演示了如何通过SqlDataSource控件去取得和修改CommandText对象中的所有参数。这对于调试的时候输出信息是非常有用的。

 

ObjectDataSource控件的执行前事件的练习

和SqlDataSource控件一样,ObjectDataSource的执行前事件也提供了一个机会去自定义要传入执行处理的参数。代替了SqlDataSource的Command对象,ObjectDataSource的执行前事件传递过来的是一个叫做InputParameters的dictionary对象,其中也包含了一些参数和值。

 

例如,就象下面的代码演示的,我们的业务对象调用了GetEmployeesByDepartmentID(departmentID)方法,其中的整型输入参数将被使用去取得制定部门内的所有员工。使用下面的代码,在ObjectDataSource对象的Selecting事件中设置这些输入参数的值。

 

Protected Sub CategoriesDataSource_Selecting(ByVal sender As Object, ByVal e As System.Web.UI.WebControls.ObjectDataSourceSelectingEventArgs) Handles CategoriesDataSource.Selecting
   
'Set parameter value through e.InputParameters
   e.InputParameters("departmentID").Value = 7
End Sub 

如果想得到更多的关于给ObjectDataSource控件设置参数的信息,请参考Programmatically Setting the ObjectDataSource's Parameter Values [VB]文章。

 

 

ObjectDataSource和SqlDataSource控件的执行后事件的练习

在指定处理执行完成后,SqlDataSource和ObjectDataSource控件引发了相应的处理后事件(Selected、 Inserted、Updated或者Deleted事件)。在处理后事件中,能够得到被影响的行数是否有异常出现。ObjectDataSource控件的处理后事件句柄传递了一个值到指定的处理方法中。例如数据库down掉了,输入了非法字符,动作违反了约束条件等异常出现了,或者其他的原因。再者,如果一个异常发生了,ExceptionHandled属性被设置成True,表明了异常被截获了。

 

如果想得到使用ObjectDataSource的执行后事件中处理异常的信息,请参照Handling BLL- and DAL-Level Exceptions in an ASP.NET Page [VB]文章,如果你使用的是SqlDataSource控件,请参照Fredrik Normen的blog中的Handle the Data Source Control Exception on Your Own文章。

 

结论

当使用SqlDataSource和ObjectDataSource控件取得和修改数据的时候,执行前和后事件被引发。通过为那些事件创建的事件句柄,我们可以在这些事件处理函数中检查下面的工作流程,输出执行使用的参数,或者检查结果。处理前事件一般用作给数据控件初始化要在执行中用到的参数。执行后事件一般用来确定多少的记录被真正的处理了或者来确定是否这个操作引发了异常。在调试的过程中执行前和执行后事件都是非常有用的。


代码下载 

posted @ 2006-12-22 16:11 姜翊华 阅读(363) 评论(0) 编辑
 

2006年12月15日

如果发表文章到哪里去了?
今天发表了一篇文章,提交了以后不知道哪里去了,在哪里也看不到,没办法和大家共享,结果删除了,从新发到随笔里,奇怪.
posted @ 2006-12-15 15:34 姜翊华 阅读(314) 评论(3) 编辑
 
[翻译]AppSettings In web.config by K.Scott Allen
                                                AppSettings In web.config

                                                                                                                                                  Written by K. Scott Allen 
                                                                                                                                                   Translated by jiangyh

      ASP.NET提供了一个灵活的配置文件管理功能。在这篇文章中我们将介绍一些使用技巧和最好的使用方法来让我们取得最好的结果。


      web.config
文件中的<appSettings>元素可以用来存储连接字符串、服务器名、文件路径或者其他各种各样的配置信息。appSettings中的这些配置信息结构或内容由于受系统环境的影响时常是变化的,例如,任何的数据库连接字符串在我们DB服务器从测试环境调整到真正的产品环境的时候都需要变更。

      看一下下面的例子,我们来练习一下如何从web.config文件中的<appSettings>段内取得连接字符串。Web.config的配置如下

<?xml version="1.0" encoding="utf-8" ?>
<configuration>   
  
<system.web>
    
<compilation defaultLanguage="c#" debug="true" />
  
</system.web>
  
<appSettings>
    
<add key="ConnectionInfo" value="server=(local);database=Northwind;Integrated Security=SSPI" />
  
</appSettings>
</configuration>

   使用命名空间System.Configuration下的ConfigurationSettings类去取得连接字符串的内容,代码如下:

 1private void Page_Load(object sender, EventArgs e)
 2{
 3  string connectionInfo = ConfigurationSettings.AppSettings["ConnectionInfo"];
 4
 5  using(SqlConnection connection = new SqlConnection(connectionInfo))
 6  {
 7    connection.Open();
 8    // perform work with connection
 9  }
         
10}


   一般情况下一些应用程序中会将上面的代码复制到整个系统的很多地方,如果我们仔细的考虑一下,这在未来可能是个很麻烦的事情。

第一,我们通过不可变的代码(hard code)去取得web.config文件中的连接字符串,虽然比较容易实现,但是在连接字符串需要变化的时候很难去适应变化。

第二,这样的代码会让我们这部分配置信息完全束缚在web.config文件的appSettings中,使用web.config只是一个保存设置的办法,在未来我们可能会发现我们需要从数据库中取得这些设置信息或者改变这些配置信息从应用程序范围变化到每个客户的级别的Session或Cookie中的时候,都会有很多束缚。

 

   封装

 

   让我们使用一个类中的静态属性来保存这个连接字符串。


 1using System.Configuration;
 2namespace aspnet.config
 3{
 4  public class Configuration
 5  {
 6    public static string ConnectionInfo
 7    {
 8      get
 9      {
10        return ConfigurationSettings.AppSettings["ConnectionInfo"];
11      }

12    }

13  }

14}


   现在我们的Page_Load方法就像下面的代码一样。

1private void Page_Load(object sender, EventArgs e)
2{
3  using(SqlConnection connection = new SqlConnection(Configuration.ConnectionInfo))
4  {
5    connection.Open();
6    // perform work with connection
7  }
         
8}

   这样的改变可以使我们上面的代码变的相对的小一些,但是更强大。现在Page_Load方法不知道将取得到什么样的连接字符串。我们可以很容易的改变ConnectionInfo属性,从不同的代码中取得连接字符串,并且不用修改其它使用这个属性的代码。我们也不需要去记住连接字符串的键值并且复制到程序中的很多地方。反而,当我们访问Configuration类去取得需要的配置信息的时候,可以利用Visual Studio Intellisense。这个key在系统中只出现一次,所以我们可以再次改变连接字符串的key,而只需要修改一行代码。

 

   当然这个方法就是原本所有代码从web.config文件中取得配置信息变化成了通过访问Configuration类来取得。我们还需要在Configuration类中增加所有的属性来匹配web.config中的配置信息。

 

   这个方法的另外一个优点就是如果我们的配置信息的内容不是一个字符串的时候,例如是日期类型,数字类型或者原始的类型,在这种情况下,我们可以在Configuration类中的ConnectionInfo中进行适当的转型来返回我们需要的类型。

 

   你将注意到了我提供了一个read-only属性给ConnectionInfo。web.config不是一个不被更新的常量。ASP.NET程序在运行的时候可以检测到web.config文件是否有变化。当ASP.NET程序发现你更新了web.config文件,任何的处理信息,例如Session, Application和 Cache都将会丢失(如果session没有存放在state服务器或者数据库中的时候)。

 

   下面,让我们来看看appSettings的一些其他特点。

 

   多文件配置

 

   appSettings元素可以包含一个文件属性来指向一个扩展的文件。让我像下面一样改变一下我们的web.config文件。

<?xml version="1.0" encoding="utf-8" ?>
<configuration>   
  
<system.web>
    
<compilation defaultLanguage="c#" debug="true" />
  
</system.web>
  
<appSettings file="testlabsettings.config"/>
</configuration>

   下面我们来创建一个新的文件[testlabsettings.config],并且增加一个appSettings段和连接字符串的信息。

<appSettings>
  
<add key="ConnectionInfo" value="server=(local);database=Northwind;Integrated Security=SSPI" />
</appSettings>

   如果这个扩展文件是可见的,ASP.NET能够包含web.config中appSettings段的配置信息和扩展文件的配置信息。如果一个key/value在web.config文件中和扩展文件中都存在的情况下,ASP.NET将使用扩展文件的值。

 

   当你保持用户特定或者环境特定的配置信息在扩展文件里的时候,上面的例子将非常有用。当每一个用户或者安装的网站需要包含他们自己的配置文件的时候,请让web.config来包含这些文件并把这些配置信息作为一个全局的实例来使用。这个方法可以很容易去围绕这个全局的web.config文件变化并且也可以将web.config文件封装到控件里,而每个开发人员还可以得到他自己的设置。

 

   有一点需要警告,ASP.NET程序无法在运行的时候检测到扩展文件的变化,你将需要手动改变web.config文件本身来启动一个新版本的ASP.NET程序

 

   我希望本文可以在最大的程度上提供给你一些appSettings段的小技巧,如果需要更好的方法去处理配置信息,请去下载Enterprise Library。

posted @ 2006-12-15 15:31 姜翊华 阅读(425) 评论(0) 编辑
 

2006年12月14日

如何选择适合项目的framework.
      最近一段时间都在研究.net的各种framework。虽然看了很多,但是了解的都不是很深。同时也产生了一个问题,就是到底项目该如何选择合适的framework,都应该从那些方面去考虑。
      其实我一直做的项目规模都不是特别的大,其中还包含很多的日本项目,本身使用framework的机会都很少。但是最近2年的失败率突然的增加,由于最近2年日本经济复苏,增加了很多的机会,一些小企业都开始更新软件,但是对应小企业的软件做法还和以前对应正规大企业一样,不适合小企业业务需求本身了解不清楚并且多变化的特点(其实软件行业各方面一直都在想办法来达到适应变更,容易扩展),而我在项目中发现大部分时间都花费在变更和变更测试上,并且变更起来非常的麻烦,自然最后就会导致延期,虽然对我们外包形式的公司来讲,这个问题不在我们,但是项目失败心里总不是滋味。所以就有了个打算来和大家探讨一下该如何选择合适的framework。

      我先把我知道的.net的framework罗列一下。
      1.Spring.net
      2.NHibernate
      3.IbatisNet
      4.Castle
      5.EnterpriseLibrary
      6.NBear

      有点混乱,希望大家不要介意,不足的还请大家补充。

      其实我一直想找到的就是哪个framework更适合小的项目,更轻量级。

      在以后的文章中希望和大家共同寻找到一个判断和使用各种framework的办法。
posted @ 2006-12-14 16:47 姜翊华 阅读(149) 评论(5) 编辑
 
顺利的加入俱乐部
  一直就希望加入俱乐部,今天突然看到了申请办法,如愿以偿的成功加入,非常高兴,祝贺自己一下。
  希望以后和大家多多交流,共同进步。
posted @ 2006-12-14 15:59 姜翊华 阅读(58) 评论(0) 编辑
 

2006年3月27日

从来不要停止怀疑

  昨天闲来无事,突发奇想从朋友那里借来温伯格的《程序开发心理学》拜读一下,经历2小时,共阅读了两章,就感觉受益匪浅。

   其中最为经典的关于优秀程序的评论,

       因为我们期望,随着岁月的推移,我们能够听到的关于效率的言论将会越来越少-----而与此同时,却越来越多地强调有效性。

  其中明白的说明了一个程序的评判标准不是效率。

  第一是有效性,就是真正的满足了客户的需要,正确的实现预期的功能。

  第二是纳期,退后一个月的纳期可能导致不可估计的损失。

   经历了好多年的软件开发,是不是每次都能正确的完成客户的需求呢。

posted @ 2006-03-27 21:42 姜翊华 阅读(227) 评论(2) 编辑
 
仅列出标题