bigqiang 的个人资料多多小虫 天行健日志列表留言簿更多  |  工具 帮助 |
|
|
2009/11/4 《Programming ASP.NET 3.5中文版：第4版》译序
翻译前，我搭建了书中要求的系统环境，并且尽可能测试翻译中遇到的每个示例，同时在可能的情况下阅读书中建议的外部资料。这对理解原文很有效，同时还能纠正一些原文中的小错误。比如，原书第12章中曾引用了微软IIS团队所维护网站的几个链接实际却不存在，这极有可能与网站改版调整了链接形式有关。在O’Reilly网站上提出该问题后，很快就得到了回应，根据官方的勘误我修正了这个错误。O’Reilly响应颇为及时，在我写这篇序时我所提交的大部分勘误建议都得到了反馈。因此可以说，我所翻译的中文版内容已经修正了英文版书中所有已知的错误。 为求证某个专用词汇的准确译法，我常去MSDN中文版页面海量文档中检索相关信息。在第13章遇到过一个词“Breadcrumb”，如果直接用“面包屑”来翻译，肯定会有很多人对上下文意思不知所云。在寻找了一些资料后也终于理解了作者为什么要用这个词，但是我就是在中文中找不到对应的词语来翻译它。我想这应该就是文化背景差异造成的吧。这个词的典故就出现在西方儿童的睡前故事中，他们只要一见到这个词就能明白作者想要表达的意思。但是我在向身边朋友求助帮忙翻译这个词时，需要费很多口舌才能让他们明白。最后经过反复思量译成了“面包屑导航”，至少看到这个译法能让大家知道这是一种特定的导航类型了。就是看起来这么简单的事也让我折腾了很久，翻译真是件辛苦的事。但是只要能让大家理解原文所传达的意思，辛苦也就不算什么了。 老实说，我对自己的翻译原本还是很自信的，但是当看到审校的文档中批注纵横时，不禁有点吃惊，原来还是存在很多错误的。在此对负责审校我的译稿的覃彬彬表示感谢。 3月下旬ASP.NET MVC 1.0正式版发布，当得到这个消息时我正在翻译中。但是这本介绍ASP.NET的书并没有一章专门的篇幅来介绍MVC这种将成为主流的开发技术。在本书作者成书之时，对于尚未定型的产品确实不方便多说。我理解这一点，不过这种无可奈何的事情多少让我感到有些遗憾。 有个朋友翻了翻样书问：书皮上印的是什么东东？我竟不知道如何回答，翻译了这么久却没细想过这个问题。为此，我去找了些资料研究了一下，总算了解了一些情况，O’Reilly的书似乎从很久前就开始用各种动物图片做封面，本书所用的动物形象是一种形似吉他的犁头鳐（Guitarfish）。至于该动物与本书内容有什么联系，则始终没有看到相关资料说明。根据O’Reilly曾经的说法，采用动物做封面外观是根据读者的评论。 自己的调查，以及分销渠道反馈的意见，也只是为了给枯燥无趣的技术书籍带来些生气。查阅这些资料的同时也注意到另一个有趣的事实：从本书的第一版到第四版都采用了相同的动物形象，前三版说明中都声称这是一种叫刺鳐（Stingray）的鱼，可是到本版时被改称为犁头鳐。这应该是O’Reilly公司犯的一个错误吧。翻译中遇到这样的事，也蛮好玩的。 将翻译过程中的一鳞半爪罗列于此，作为序。 邹建强 ------------------ 后记：现在Google Sites服务国内已经不能访问 2006/8/5 Asp.Net数据库编程－10条最优方法[翻译]原文标题:Using Data with ASP.Net - 10 of my 'Best Practices'
原文链接:http://www.developerdotstar.com/community/node/531 (By Chris Gaskell) 翻 译:bigqiang(多多小虫) 说 明:学习之用，翻译未经原作者许可 完全不能说：任何严谨的程序员在他们的职业生涯中极少有时间处理数据库编程。因此要求你涉及底层数据库的代码尽可能高效非常合理。希望能把我在应用ADO.Net编程时所了解的一些最佳编程方法与你分享。也希望你能在使用过程中发现和我所说的同样有效。
最优方法 #1
使用内置.Net data providers 内置的.Net data providers允许你充分利用.Net框架特点以及高效发挥数据库的潜力。
最优方法 #2
总是使用conifg文件保存数据库连接字串。同时加密连接字串特别是数据库位置不确定时。 在程序外部的数据库可能会变动位置，这样可以很容易的更改config文件中的连接字串。从安全角度讲加密连接字串很明智。
最优方法 #3
优先作用SQL Server的排序方法，诸如：ORDER BY，HAVING 以及 GROUP BY 这些语句。 在服务器端执行排序而不是在客户端，这会更节省时间，因为服务器端完成任务更快。
最优方法 #4
尽力设法限定返回结果集合的行数，具有代表性的方法是使用 TOP 关键词，当然还有其它类似的方法。 限制发送信的息数据量程序会更快
最优方法 #5
当使用一个 Command 对象的 ExecuteReader 方法时，最好使用CommandBehavior.CloseConnection 这种方式提供了良好的连接池，能让连接迅速打开和返回。
最优方法 #6
如果在关闭DataReader对象之前你就已经结束读取不再想读取更多记录行的最好马上取消读取操作。 DataReader类的关闭方法最终关闭对象前会不断读取所有余下的记录行。这太浪费资源。
最优方法 #7
最好使用参数化的command（通常是存储过程）来处理动态的SQL查询。 这会改善性能减少SQL注入攻击的机会，同时你的代码也更容易维护。
最优方法 #8
在处理50或50条以上的记录行时最好对排序结果集进行分页。 虽然多数情况下使用分页技术不太容易，但是它能让服务器端数据库和客户端应用程序减少任一时刻的开销和网络流量提高性能，
最优方法 #9
在所有记录中加一个时间戳字段——我通常用‘creationdate’（创建日期）、‘lastupdate’（最后更新日期）字段。 数据库内容被更新时，这会更容易检查。同时也更容易检查代码与数据源互操作的正确性。
最优方法 #10
不要通过象 “SELECT * ”这样的方式返回数据。 尽管一个“SELECT *”语句是编程最快速的写法，但它肯定是返回所有记录操作速度最慢的，难道你真的需要频繁访问所有列记录吗？请明确写出你要访问的列字段。
=============================
译文结束，以下是一些我看到的一些评论也一并翻译出来：
-------------
Phil(http://weblogs.asp.net/plip):
关于第5条，我更进一步。要确保你使用using语句 Using Conn As New SqlConnection() using (SqlConnection Conn = new SqlConnection()) 这会确保清空所有资源。 -------------
Michel(http://blogs.wdevs.com/qc/):
关于第6条“DataReader类的关闭方法最终关闭对象前会不断读取所有余下的记录行”。你肯定吗？我认为在Read()方法中就完成了这个工作。 -------------
Shahed Khan(http://geekswithblogs.net/shahed):
为了回答第10条“难道你真的需要频繁访问所有列记录吗？”，我想说有许多人在使用N层模型的业务对象中使用了所有的列字段并且填充大量的业务对象。 Chris Gaskell回复：我明白你所说的依据是什么，但是在你的业务DTO(译者：详细的试验目标？)中你也要包括诸如“DateCreated”和“LastModified”这样的字段吗？ -------------
David Parslow(http://parslow.spaces.msn.com/):
动态SQL查询实现以参数化command的来改善性能(想象中优于存储过程，但此处有争议)，减少了SQL注入攻击的机会(因为它被参数化了)，并且更容易维护代码(可以和OR-Mapper或者类似的技术)。所遇到的这些问题应该是静态查询(这比较常见) Chris Gaskell回复：似乎我给动态SQL查询一词的定义并不清楚。请看下面的一个动态查询示例（我想你能发现这和你的静态查询描述比较符合）
sql = @"SELECT Col1, Col2 FROM table WHERE id=" + id; -------------
Richard Jonas(http://www.richardjonas.com/blog):
我想补充一个方法： 建立一个有限数量SQL查询列表，并把它保存在一个共用文件里，而不是让这些查询语句出现在所有代码文件当中。 如果以后更改数据库，这会产生一些问题，计划中要更改所有影响SQL查询的文件，如果把SQL查询保存在一个共用文件里，并限制数量，这会减少更改量降低遗漏某些重要问题的风险。 |
|
|
