软件开发专业英语的书籍

读软件开发方面书籍自己似乎有偏好，不喜欢看国内作者写的（不过有好书也是看的，比如博文视点的好多原创经典书籍）大部分看的是国外书籍的译本（英语不好只能看译本），译本也是有选择的，如果是一堆人翻译的基本也不看，除非这本书讲的方面确实就这么一本书，并且翻译的也不赖。博客园有一.NET方面的牛人名叫“老赵”，他的博客格言是“让老外看中国人写的计算机书籍”，甚是敬仰。过年前后接手的项目是一个“客户端数据录入”的软件，之前开发的都是B/S软件，对WinForm开发中的某些要求也不甚了解，所以按着WEB软件的模式来建立“数据连接层”、“业务逻辑层”。其实自己使用了一个“SocanCode”的代码生成器来生成了“数据连接层”和“业务逻辑层”，由于客户要求的这个客户端软件除了要有一个“中心版”还要一个“部门版”的（软件为什么没有直接设计成B/S版的呢？因为客户的理由是“部门版”的用户可能没有网络，并且点名要搞两个版本），考虑到性能方面的要求所以“部门版”数据库用Access，“中心版”使用SQLServer2000个人版，所以这个“代码生成器”生成了两套“数据连接层”代码，真是不错的东西。“SocanCode”生成的代码类似于“PetShop4”，模式的代码，“数据实体模型”部分直接就是实体类，软件在实现的时候碰到一个问题：数据库的某些字段的值与其他字段有隐藏的“关联”关系，比如一个XX号=某些字典字段+某些字典字段+自编号。数据库在设计的时候实际上已经违背了某些“数据库设计范式”，因为为了最后呈现的时候方便，也为了客户在导出数据的时候方便。为了实现这个“关联”最后每个“数据实体模型”实现了“System.ComponentModel.INotifyPropertyChanged”接口，来“通知”某些列的更改，通过“PropertyChanged”事件来捕捉“通知”，再“Remove”事件，更改某些“关联”关系的字段值，再“Add”事件来完成整一个“关联”关系字段的控制。虽然实现起来麻烦了点，但客户再提“关联”关系字段更改的需求改的就很方便了。软件交付之后，经过几次的BUG修改，客户数据录入接近尾声之后，客户要求“中心版”软件“数据横表（起始就是一个GridView）”部分要有可编辑功能，因为“部门”录入的数据太乱了，需要快速编辑修改功能。问题出来了“得到数据横表更改，保存数据横表更改的数据”怎么解决？记得学习.NET的时候使用DataSet+DataAdapter来完成数据绑定到表格，批量更改后“DataTable.GetChanges()”更改，保存数据，再“DataTable.AcceptChanges()”更改，就可以了。事情到了这个步骤更改成DataSet来实现肯定软件动的地方不少。最后解决的办法是“数据横表”绑定的“数据实体列表”转换成“DataTable”，修改完成后再转换成“List”类型的数据列表，再保存数据。在更改这个“横表”编辑功能的时候又发现一个问题“用户录入表单编辑的数据撤销操作后无法回复原来数据”，记得一本好像是“ExpertC#2005BusinessObjects”书籍上讲到“多层撤销”的问题，解决的方法是“数据实体模型”实现了“System.ComponentModel.IEditableObject”结构，使得实体模型对象具有了“BeginEdit、CancelEdit、EndEdit”功能，为了期间的一个数据拷贝功能“数据实体模型”又实现了“System.ICloneable”接口。最后总算所有的问题都解决来了，好像很累人，还好在处理数据“关联”问题时没有去实现“System.ComponentModel.IBindingList”接口。似乎自己在开发WinForm软件的时候犯了很大错误——把WinForm当成了WEB程序来开发，结构一开始就错了。如果一开始使用“强类型数据集”也没有多少错误（没有用的原因是自己在原先的WEB开发中因为使用“强类型数据集”，在后期给自己维护造成了很大的麻烦），最后为了实现某些功能自己实现了一个超级简化版的“DataTable”，自己在为了实现“数据实体模型”可以“GetChanges()”的时候差一点把“数据实体模型”进行了一个大规模的代码重构（因为在CodeProject上一篇文章讲到了可以使得得到“实体模型类表”具有“GetChanges()”功能的方法）。清明节到图书城看到了《EffectiveC#》这本书，其实自己从前看过这本书，只是没有认真的看，其中的的第41条：《选择DataSet而不是自定义的数据结构（PreferDataSetstoCustomStructures）》，看了之后真是羞愧万千，怪自己没有认真的领悟书中的东西，下面是内容摘要：因为两个原则，把DataSet的名声搞的不好。首先就是使用XML序列化的DataSet与其它的非.Net代码进行交互时不方便。如果在Web服务的API中使用DataSet时，在与其它没有使用.Net框架的系统进行交互时会相当困难。其次它是一个很一般的容器。你可以通过欺骗.Net框架里的一些安全类型来错误DataSet。但在现代软件系统中，DataSet还可以解决很多常规的问题。如果你明白它的优势，避免它的缺点，你就可以扩展这个类型了。DataSet类设计出来是为了离线使用一些存储在相关数据库里的数据。你已经知道它是用来存储DataTable的，而DataTable就是一个与数据库里的结构在行和列上进行匹配的内存表。或许你已经看到过一些关于DataSet支持在内部的表中建立关系的例子。甚至还有可能，你已经见过在DataSet里验证它所包含的数据，进行数据约束的例子。但不仅仅是这些，DataSet还支持AcceptChanges和RejectChanges方法来进行事务处理，而且它们可以做为DiffGrams存储，也就是包含曾经修改过的数据。多个DataSet还可以通过合并成为一个常规的存储库。DataSet还支持视图，这就是说你可以通过标准的查询来检测数据里的部份内容。而且视图是可以建立在多个表上的。但是有些人想开发自己的存储结构，而不用DataSet。因DataSet是一个太一般的容器，这会在性能上有所损失。一个DataSet并不是一个强类型的存储容器，其实存储在里面的对象是一个字典。而且在里的表中的列也是字典。存储在里的元素都是以System.Object的引用形式存在。这使得我们要这样写代码：…省略中间部分…花了几页的代码来支持一些已经在DataSet里实现的了的功能。实际上这还不能像DataSet那样恰当的工作。例如交互式的添加一个新记录到集合中，以及支持事务所要求的BeginEdit,CancelEdit,和EndEdit等。你要在CancelEdit调用时检测一个新的对象而不是一个已经修改了的对象。CancelEdit必须从集合上移除这个新的对象，该对象应该是上次调用BeginEdit时创建的。对于AddressRecord来说还有很多修改要完成，而且一对事件还要添加到AddressList类上。最后就是这个IBindingList接口。这个接口至少包含了20个方法和属性，用于控件查询列表上的功能描述。你必须为只读列表实现IBindingList或者交互排序，或者支持搜索。在你取得内容之前就陷于层次关系和导航关系中了。我也不准备为上面所有的代码添加任何例子了。几页过后再问问你自己，还准备创建你自己的特殊集合吗？或者你想使用一个DataSet吗？除非你的集合是一个基于某些算法，对性能要求严格的集合，或者必须有轻便的格式，就要使用自己的DataSet，特别是类型化的DataSet。这将花去你大量的时间，是的，你可以争辩说DataSet并不是一个基于面向对象设计的最好的例子。类型化的DataSet甚至会破坏更多的规则。但，使用它所产生的代码开发效率，比起自己手写更优美的代码所花的时间，这只是其中一小部分。经典的书籍往往就是经典，C++方面经典的书籍一版一版的发布，一次一次的印刷，看得人津津乐道，JAVA方面的书籍也是这样。C#方面因为也就八九年的时间，经典的书籍似乎少了点，大概是翻译成中文的不多（国人写的似乎流行不起来），但一本《EffectiveC#》虽然讲解的是“C#1.0”方面的内容，但毕竟是.NET方面的，内容很经典。这些天闲了在看一本《企业应用架构模式》的书籍，书籍至少是03年之前的写的，到现在.NET软件开发设计方面的内容也有很多进步，但这本书讲的确实很不错，用现在的眼光来看作者讲的确实很有前瞻性，应该是自己并不了解企业软件开发方面的内容，这么多年自己只能从七七八八的书籍上来自己体会企业软件开发，看到这本书真是眼前一亮。