C#中将表数据导入Excel一般都是将数据逐个Cell的插入到Excel里。如下（只是代码片断）：
…
Object missing = Missing.Value;
Excel.Application myexcel = new Excel.Application(); //新建EXCEL实例
myexcel.Application.Workbooks.Open(filename, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing, missing); //打开filename表
myexcel.Visible = false;
Excel.Workbook myworkbook = myexcel.Workbooks[1];
Excel.Worksheet myworksheet = (Excel.Worksheet)myexcel.Worksheets[1];//声明一页的实例
…
for (int i = 0; i < rownum; i++)
{
GridViewRow gvr = mydata.Rows[i];
for (int j = 0; j < colnum; j++)
{
myexcel.Cells[i + 8, j + 1] = "'" + gvr.Cells[j].Text.Replace(" ","");
}
}
…
但是，由于对Excel的Cell赋值效率很低(因为每对Cell赋一次值都回导致调用一次Excel COM+组件的接口)，所有如果数据多起来的话，对Excel COM+组件的访问就会很频繁，从而导致程序运行效率极其低下。
要解决这个问题主要是减少对Cell的访问次数。查阅Excel的API可知，可以通过对它的一个属性Value2赋值（数组）来实现和上述代码一样的作用。这就可以避免了频繁访问Cell而导致的性能急剧下降。
改进后的代码如下：
…
Array arr = Array.CreateInstance(typeof(String), rownum, colnum);
for (i = 0; i < rownum; i++)
{
for (j = 0; j < colnum; j++)
{
arr.SetValue(mydata.Rows[i].Cells[j].Text.Replace(" ", ""), i, j);
}
}
Excel.Range range = myworksheet.get_Range(myworksheet.Cells[5, 1], myworksheet.Cells[rownum + 4, colnum]);
range.Value2 = arr;
…
BTW：老是觉得Excel的属性Value2的命名看起来很不舒服，有点不是很规范。不知他们为什么要这样命名。
2.代码就是设计文档(source code is a design document)
对于传统的工程学,设计与构建是可以分离的.但是对于软件工程来说,所有的工作都是设计性的.
3.需求是不可预知的和不断变化的,尝试去预测不可预知的需要是危险的
一些软件公司先把需求写好,让用户签字确认.然后以该需求文档为中心进行开发,其间只允许极小的需 求变化.不过这是不可行的或者说是不负责任的做法.
需求变化是很令人头痛的.当你在做一个商业软件时,即使客户不想改变需求,他所处的市场环境也迫使 他改变,所谓商场如战场.曾经做过一个该类型的软件.结果是软件一直在做,需求一直在改,当时感觉是 这个项目好像永远做不完那样.
4.以人为本!开发人员不是拿来就兼容的编程单元
5.开发人员应该更积极的参与到项目中去,自己制订工作计划
开发人员应该与管理人员和用户保持紧密联系.的确,由于软件是做出来供人使用的,所以开发中应该掺杂更多人的因素.这就促使了软件开发涉众要紧密联系.开发人员应该积极主动的参与到项目的管理中去,与管理人员地位相同,并且应该由开发人员决定如何开展项目---这个观点与传统的管理学理论的观点存在矛盾.
6.应该怎样开始尝试敏捷开发?
应该找一个项目规模在比较容易管理的范围之内的项目开始尝试敏捷开发.该项目最好不要是一些毫无重要性的项目.
7.敏捷开发应用范围不单单是较小的项目.
8.不能强迫不愿意使用敏捷方法的开发团队去使用该方法.对于不愿遵循敏捷方法的客户,要尽量使他们参与到项目中来.
好不容易等到收废品的人经过.称了一下,有15斤(还不轻!).他心算了一下,报了个价--15块大洋!还不到一本书买进的价格.
当场感慨万千.当有利用价值的时候,书里面凝结的知识真实价格不菲啊.但没有利用价值时,就是废纸一堆,不值一文!
所谓SQL注入式攻击，就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。在某些表单中，用户输入的内容直接用来构造（或者影响）动态SQL命令，或作为存储过程的输入参数，这类表单特别容易受到SQL注入式攻击。常见的SQL注入式攻击过程类如：
⑴ 某个ASP.NET Web应用有一个登录页面，这个登录页面控制着用户是否有权访问应用，它要求用户输入一个名称和密码。
⑵ 登录页面中输入的内容将直接用来构造动态的SQL命令，或者直接用作存储过程的参数。下面是ASP.NET应用构造查询的一个例子：
System.Text.StringBuilder query = new System.Text.StringBuilder(SELECT * from Users WHERE login = )
.Append(txtLogin.Text).Append( AND password=).Append(txtPassword.Text).Append(); ⑶ 攻击者在用户名字和密码输入框中输入或1=1之类的内容。
⑷ 用户输入的内容提交给服务器之后，服务器运行上面的ASP.NET代码构造出查询用户的SQL命令，但由于攻击者输入的内容非常特殊，所以最后得到的SQL命令变成：SELECT * from Users WHERE login = or 1=1 AND password = or 1=1。
⑸ 服务器执行查询或存储过程，将用户输入的身份信息和服务器中保存的身份信息进行对比。
⑹ 由于SQL命令实际上已被注入式攻击修改，已经不能真正验证用户身份，所以系统会错误地授权给攻击者。
如果攻击者知道应用会将表单中输入的内容直接用于验证身份的查询，他就会尝试输入某些特殊的SQL字符串篡改查询改变其原来的功能，欺骗系统授予访问权限。
系统环境不同，攻击者可能造成的损害也不同，这主要由应用访问数据库的安全权限决定。如果用户的帐户具有管理员或其他比较高级的权限，攻击者就可能对数据库的表执行各种他想要做的操作，包括添加、删除或更新数据，甚至可能直接删除表。
二、如何防范？
好在要防止ASP.NET应用被SQL注入式攻击闯入并不是一件特别困难的事情，只要在利用表单输入的内容构造SQL命令之前，把所有输入内容过滤一番就可以了。过滤输入内容可以按多种方式进行。
⑴ 对于动态构造SQL查询的场合，可以使用下面的技术：
第一：替换单引号，即把所有单独出现的单引号改成两个单引号，防止攻击者修改SQL命令的含义。再来看前面的例子，“SELECT * from Users WHERE login = or 1=1 AND password = or 1=
第二：删除用户输入内容中的所有连字符，防止攻击者构造出类如“SELECT * from Users WHERE login = mas -- AND password =”之类的查询，因为这类查询的后半部分已经被注释掉，不再有效，攻击者只要知道一个合法的用户登录名称，根本不需要知道用户的密码就可以顺利获得访问权限。
第三：对于用来执行查询的数据库帐户，限制其权限。用不同的用户帐户执行查询、插入、更新、删除操作。由于隔离了不同帐户可执行的操作，因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT、UPDATE或DELETE命令。
⑵ 用存储过程来执行所有的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。
⑶ 限制表单或查询字符串输入的长度。如果用户的登录名字最多只有10个字符，那么不要认可表单中输入的10个以上的字符，这将大大增加攻击者在SQL命令中插入有害代码的难度。
⑷ 检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。
在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本（或者直接删除脚本），然后将非法内容通过修改后的表单提交给服务器。因此，要保证验证操作确实已经执行，唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象，例如RegularExpressionValidator，它们能够自动生成验证用的客户端脚本，当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象，你可以通过CustomValidator自己创建一个。
⑸ 将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。System.Web.Security.FormsAuthentication类有一个HashPasswordForStoringInConfigFile，非常适合于对输入数据进行消毒处理。
⑹ 检查提取数据的查询所返回的记录数量。如果程序只要求返回一个记录，但实际返回的记录却超过一行，那就当作出错处理。