自定义可绑定数据的业务对象实体和强类型-Part One

译者序:

在前一家公司做的最后一个项目中,有需要使用到强类型DataSet,当时只是希望要研究一下强DataSet,所以搜集了一下资料,发现深入的不是很多,反复看了这篇文章发现很不错,不过是英文版本的,而且比较的长,但是俺还是立志要翻译一下,不过这是俺第一次翻译英文技术文章,肯定会有很多不到位的地方,我先原谅自己:);

     这篇文章主要从DataSet说开,涉及到很多相关知识,这里面还涉及到一些其他的技术层,如Entity和Object的映射,事件和接口的应用,分层开发,DataAdapter适配器,另外还涉及到一些VS2005对强类型DataSet的创建和配置的步骤;

     俺的博客也是刚刚开张,第一次使用cnblogs,刚才也是试了几个客户端工具,现在暂时使用Zoundry Blog Writer,这两天还是边整理边发布翻译好的文章;另外,里面有一些名词保留了英文原版,在括号中做了翻译,原因很简单,怕把简单的东西搞复杂了;

原文地址: http://www.codeproject.com/KB/database/CustomBindableObject.aspx

章节目录:

......译者序
......介绍
......使用代码
.........步骤一 : 创建数据存取层
.........步骤二 : 创建自定义业务层
.........步骤三 : 创建表现层
.............在Windows窗体中呈现数据
.............对数据库做增,删,改操作

译者测试环境:
Windows Server 2003 R2 sp2 + SqlServer2005(Northwind数据库自己搞定) + Visual Studio 2005 Team Suite;

介绍:

关于开发人员通常应该使用哪种技术,从数据层通过业务层向表现层呈现数据,已经有并且仍然有许多相关讨论.总结一下,主要有两种主要思想潮流并存.一部分坚信"唯一对象的套路"(因此,他们使用O/R映射工具将数据库字段映射到自定义对象的属性),而另一部分人使用的强类型DataSet作为媒介,在表现层中呈现数据.

几年前,作为一名.NET设计师,我时常不得不做这个艰难的决定.因为,那个时候在.NET框架中绑定一个自定义业务对象不如现在方便和容易,我最后决定,创建一个业务对象,让它带有"强类型DataSet"作为数据容器,并且实现一些基础"业务类"来揭示出验证数据容器的"行"中数据的一般方法.

尽管如此,在如今的开发过程中,仍然有个不变的东西,就是,我们应该部署分离的的层( 举例说吧:一个层是我们代码的逻辑分离,一个层是物理分离,意味着一个逻辑层的应用程序会允许在一个单独的机器上,一些逻辑的(像远程调用或者Web服务)功能组件可以添加,使之可以运行在单独的层(机器)上 ).

好吧,因此我决定选择故事中DataSet这个"阵营",并且… 仍然会有一些人认为强类型DataSet是愚蠢的,并且给管理带来的不便,我觉得(并且继续觉得...)在业务层中进行这种愚蠢的部署很舒适!无需揭示O/R映射,数据库中的数据以透明方式带到表现层,并且,关联数据的处理更是小菜一碟!好吧… 如果你改变"数据库",你必须要做一些"通道",来使程序再次编译(单纯的用户对象你不会遇到错误,但是如果你忘记向你的业务类中添加新属性(对于从代码生成器中解放自己的人而言),你就不会注意到,已经得到新的属性数据).

"以数据为中心"(DataSets)和"以对象为中心"(Custom Objects)这两个词永远不会和谐,但是,在.NET2.0中绑定自定义业务对象,以及自动化的数据存取(仅指SqlServer)的代码生成变得更加成熟,我将在下一篇文章中,把重点放在怎么使这两者更加和谐上.

我将要展现一个简单的逻辑分层架构,来部署一个"单纯的业务对象"的层,用做"表现层"的数据绑定,并且使用.NET2.0中数据存取能力的新特性(是的!这是建立在强类型DataSets基础上!!!)来呈现数据到我们的自定义业务对象.考虑到简单直观性,我们将坚守简单的业务对象(因此省略了缓存,业务规则等等);

发表这篇文章的原因在于,我看过一些文章或者部分代码工程,它们解释一些O/R映射和数据绑定的原则,但是,在网络上很难找到一篇真正满意的文字和完美的代码例子.不仅实现"Get()"部分(这只是简单的部分!),而且解释"Save()"部分(这是难点!),并且,不仅为了简单的数据对象,而且为了更加与真实世界关联的"父-子"数据.好吧… 如果你正在寻找这样一篇完美的例子,开始阅读这篇文章吧,我希望你喜欢它!

这篇文章将以"逐层深入"的形式展现,因此,你可以创建一个工程,从零开始,或者只是看演示代码,你可以随意选择;