我对duwamish7的一些理解(一)-.NET教程,评论及其它

前言：首先要声明的是：虽然题目后面跟了个“一”，但我不敢保证会有“二”或更多，因为我现在也是在边学边做中，而且我做的项目基本上是由我一个人来完成数据层及业务层的操作，所以我想我根本不需要像duwamish7这样分这么细的层次，也可以比较好的实现面向对象，比较好实现封装继承等。但我还是对分层设计的设计模式非常感兴趣，于是还是决定好好研究一下duwamish7这个例程。当然不排除会因为工作忙的原因而不去看这个，所以写到哪儿算哪儿。如果真的写不下去，就把一去掉得了：)
  其次，我想说明的是：对于.net以及与之相关的一些设计技术，我全部是自学，而且均是走马观花，小桥流水式的，也没有高手指点，所以我不指望我说的东西完全正确或是恰到妙处，相反，除了与大家分享我的学习体会外，我最主要的目的还是希望各位大虾给我指点一些我理解不到位或是没有理解到及理解错误的地方，在下不甚感激!!
  
   开始：初用vs.net不久的人可能会对duwamish7解决方案中的那个根图标不太理解。那是一个企业级的模板，这里选择的是“c#的小型分布式应用程序”这个模板，建立这个模板后，系统分自动把这个解决方案中的模板里分出这样几个项目：web表示层(webui)，胖客户端表示层(winui)，web服务层(webservices)，业务外观层(bussinessfacade)，业务规则层(bussinessrules)，数据访问层(dataaccess)，以及一个系统层(systemframework)。我想，既然是分成单独的项目了，应该是不同的人开发不同的项目的。
   duwamish做了一些改动，这些改动至少包括：根据需要去掉了winui层，webservice放到web中了，然后把各个项目做一个改动–编辑其项目属性–把每个项目的程序集和命名空间都加上”duwamish7.”这个块，以表示他们都是这个解决方案中的。另外，把除web层外的所有项目的输出路径(输出为类库)改为web层的bin目录下，这样就不用手工添加引用了，即更改输出路径为..\web\bin。我想duwamish那个项目可能是修改了企业模板做到这些的，但我不会，所以，我是手动一个一个改的^_^。
   但我觉得最重要的改动还是duwamish7加了一个新的项目”common”，对于这个层，我的理解是用来存放业务对象的，我想，或者说是叫实体(entity)吧，存放在common的data目录下的实体类中。总共有四个实体，以xxxdata来命名，每个实体类均继承dataset类。对这些实体的理解，我想，它们表示着在整个项目中需要操作的业务对象，我说不清在设计上是先要根据需求抽象出这些业务对象，然后根据这些业务对象来决定数据的设计，还是先对需要建模，得出数据库的设计，然后根据数据库表得出这些业务对象，我倾向于前者(没做过具体的项目，其实我对这些根本不懂)。总之，这些实体并不是和数据库表一一对应的，而是数据库表的另一种抽象，毕竟，数据库设计有它自己的规则和方法，所以可能一个实体中包含了几个数据库表共同作用的一些结果，但我想这两个东西都是为了去抽象现实中的实体。
   这些xxxdata实体和数据库表的另外区别是，这些业务对象是dataset架构，注意，是架构，表示的是整个程序操作的一个单位，而数据库表中不仅有架构，还有实实在在的数据。实体类只有在每一层中具体的实例化为实体对象，才相应的会向其中填入数据，并一层一层传到dataaccess，再写入数据库中。这个，我感觉实体类就好比int，它提供一种规格，然后在具体的程序中我们可能会int i = 5;一下，而这个i就是实体类的对象，但这不意味着int就一直是5了，下次再用int的时候，再重新实例化一个。。。。。(int好像是基类型唉，这个比喻真是不好)。
   现在我明白了为什么还要搞出个实体类来，我觉得这是各个层(子项目)之间传输的一种数据实体标准，当然，我们可以直接把表示层上的值直接传到数据层来，一个sql语句，照样写进数据库，但那可能就违背了分层的意义了。有了实体类后，在每层之间，除了传递必要的数据外，主要传送的还是实体类对象，也就是实体的数据。比如说吧，在web层中，当我得到了建立客户所需要的”帐号”，”密码”，“电子邮件”等信息后，不是直接把把这几个值传向下一层，而是把它们填入实体对象(customerdata mycustomer = new customerdata())中，把实体对象(mycustomer)传入下一层，下一层是业务层了，会对网页传过来的数值进行业务规则的分析，比如，我会检查电子邮件是否存在，这个操作是不应该在表现层做的。以我们平常所想，检查电子邮件是否存在那就直接从表现层得到电子邮件，然后一个sql查询，得到电子邮件对应的用户id，看有没有抛出异常得了。这太随意了，在分层的设计中，从表现层传过来的不是电子邮件的值，而是一个实体，是mycustomer这个用户实体，然后在业务层，我们会根据这个实体对它进行操作，包括从其中得到电子邮件的值，然后交给业务规则中验证电子邮件是否存在的方法去做。。。。。。
   这就是我对实体类的理解，它表示的是各层所操作的基本的数据单位，我们的编程也不在是有什么就传什么的一个过程，而是一个“获取值->封装->传递封装”或者是“获取封装->解封装->处理->传递封装”的过程。这样，每层的出入接口也会比较清晰，只要实体类设计好了，每层的设计可以不必管其它各层怎么设计，我只需要你传给我一个实体对象，我对这个实体对象进行操作，必要时，我在传出操作后的实体对象就是了。不知道我的理解是否恰当？
   几个实体类的定义也不是很复杂，一个实体类就是一个dataset，其构造方法调用builddatatables方法以构造一个或多个datatable，并且填充datatable架构，也就是添加datacolumn，并且根据需要，设置各个datacolumn的值是自增，还是非空等。另外给每个实体类[serializableattribute]的属性(attribute)以便可以进行remoting操作。实体类的定义好像就没什么了。
   common层我就先讲到这儿吧，另外那个文件不完全懂，也不敢怎么说。
   今天就先谈到这里吧，希望对初学者对架构的理解有一定帮助，老手们千万别笑话我，我毕竟是初学者，同时，也希望你们能帮我指点指点，提出我理解不到或不到位的地方。谢谢!