例子。新的需求就是我们要12V的电，而原来的电只能提供220V，那么我们就定义一个接口叫做"12V电源使用"，然后定一个Adapter

变压器，里面接收（组合）了220V的电源，在里面经过一系列的动作以后，实现了"12V电源使用"这个接口，传出12V电源。

设计模式中的适配器模式可以分为对象适配器和类适配器

对象适配器中适配与被适配的对象是组合关系，符合面向对象设计原则：优先选择组合方案，而不是继承方案。

类的适配器中适配与被适配的对象是继承关系，适配器要继承被适配对象和新的接口。由于C＃(vb.net)并不支持多继承，所以限制

了类适配器的使用，所以在dotnet中并不推荐使用这种适配方式。

当一个对象A不能满足新需求R时，就可以定义一个适配器Adaper，把A组合到新的Adaper中。在Adaper中使用A的功能和新功能以满

足新需求R。
这句话就说明了适配器模式。适配器就是Adaper，被适配的对象就是A，新需求R可以定义一个接口，并用适配器实现这个接口。

在软件设计过程中，也有很多不那么规范的Adapter模式，但是它们也是适配器的思想，也叫做适配器。
如果我们现在存在一个Case类，代表工作。现在有个新的需求,要求对Case根据一些条件进行排序。而Case类本身是没有排序功能的

，这么办呢？ Aapter模式就有用了。在这种情况下，我们可以做个Adapter，它实现Icompareable接口。在使用时，直接为Case数

组调用Sort方法，并传入Case数组和刚才新建的adapter对象就可以了。但是这么实现呢？在适配器（CaseAdapter)里实现一个

Compare方法，传进去两个Case对象，根据Case的某个属性，返回一个数值。根据这个值就知道哪个该放在前面了。在这里，并没有

把被适配的对象Case放入Adapter中，而是直接通过参数传入。这并没有符合设计模式的结构，但是却使用了适配器模式的思想.调用代码如下:

Code
 1 Case[] cases = new Case[] { new Case(1), new Case(3), new Case(5), new Case(44), new Case(8), new Case(555), new Case(8) };
 2
 3            Console.WriteLine("before sort");
 4            for (int i = 0; i < cases.Length; i++)
 5            {
 6                Console.WriteLine(cases[i].ItemCount);
 7            }
 8
 9            Array.Sort(cases, new CaseCompareAdapter());
10            Console.WriteLine("after sort");
11            for (int i = 0; i < cases.Length; i++)
12            {
13                Console.WriteLine(cases[i].ItemCount);
14            }
15
16            Console.ReadLine();

那么，如果标准的适配器模式结构是怎么样的呢？
假设我们现在要为Case加上一个TellAlerm的方法，但是却不能去修改Case类，这时就可以使用Adapter了。
我们新建一个CaseAlermAdapterStandard类，然后在构造方法中初始化一个Case对象。然后定义一个方法叫做TellAlarm，返回一个字符串。定义一个ItemCount，返回构造函数中的Case的ItemCount。现在就可以调用了。

调用代码如下：

Code
1 //standard structure for adapter design pattern
2            CaseAlarmAdapterStandard cAdapter = new CaseAlarmAdapterStandard(6);
3            Console.WriteLine(cAdapter.ItemCount);
4            cAdapter.ItemCount = 788;
5            Console.WriteLine(cAdapter.ItemCount);
6            Console.WriteLine(cAdapter.TellAlarm("due to deadline!"));
7            Console.ReadLine();

完整的适配器代码:Adapter design pattern

我说完这些,自己却有个疑惑,所谓适配器,是不是就是被适配的对象的所有功能+新功能呢?还是说根据需要选择被适配对象的功能?我个人觉得可能应该是根据需要选择被适配对象的功能.因为有可能我这个适配器不需要那么多功能,只需要被适配对象的一部分功能+新接口定义的功能,就可以满足要求了.

欢迎大家拍砖,我是学习设计模式的新手,希望大家多多指教.

时间比较短,还好创建型的比较简单,以后估计不会这么顺利了.由于没有真正的实践在项目中,所以到现在为止,我认为我还没有掌握,仅仅是对设计模式有些了解而已.

人家说英语是说出来的,所以我也把我知道的关于创建型的设计模式的相关知识总结出来,供大家参考和讨论,希望能与各位同仁共同进步.

创建型模式,主要用来解决new所带来的对象间的耦合关系,除了singleton和prototype之外,都需要使用factory来负责对象的实例化，prototype是通过原型（也就是抽象）来克隆对象。

白话一点儿说，创建型模式就是把有可能经常变化的对象单独拎出来处理，使这些经常变化的部分在发生变化时不会影响整个系统。

GOF设计模式有5种是创建模式.

其中Singleton模式用来控制对象创建的个数,一般是一个,可以通过变化创建指定数量的对象.

factory method模式是最最基础的创建型模式，也是最基础的设计模式之一。既然是面向对象编程，当然要创建对象。factory method模式就是解决了对象的基本创建问题。对象通过自己的工厂创建实例，在创建点不依赖具体实现而仅仅依赖于对象自己的抽象。编译时只知道要创建哪种对象（抽象），运行时才知道具体会创建这种对象的哪个对象。反正一种对象的行为都是相似的，所以抽象也是一样的。只是具体实现不同。比如车都能转弯，只是摩托车和汽车转弯的具体实现不同，但抽象是相同的。这里编译时只说车要转弯，在运行时再具体告诉程序是哪个车要转弯。

abstract factory模式是在factory method模式的基础上发展而来， factory method模式只解决了创建哪个对象的问题，而abstract factory解决了创建哪个系列对象的问题。这一系列对象之间可能有很多关联和交互。白话点而说就是，比如我们肯定都用床上用品，包括床单，被罩和枕巾等。我们不会一辈子都用一套吧，肯定要换洗的，有坏的还得换新的（这里假设整套整套坏/换）。那么abstract factory就用上了。一次创建一套床上用品，不用修改任何地方，只需要增加新的床单类，被罩类和枕巾类，然后在调用时告诉系统，我要用这个新的。就OK了，符合了面向对象的对修改关闭对扩展开放的原则。

builder模式与factory method一样，都是创建一个对象。但是它却是创建了一个超级复杂的对象。它可以让我们通过相同的创建过程创建出不同的表示。在这里，创建对象的算法是稳定的，但是对象的各个部分却是不稳定的，经常会变。比如要建造一个房子，建造房子的过程，比如打地基，搭架子，垒砖这些骨干的过程是不变的，这是稳定的算法。但是在造门和窗户的时候却有可能经常发生变化。有可能这个房子要用A工厂的门，那个房子却要用B工厂的门。这是就要用到builder模式了。不管你用谁的门，但是造出来的肯定得是房子。

prototype模式诠释了面向对象的依赖倒置原则。当一个Manager对象依赖某个具体实现时，我们把这个实现抽象出来（前提是这个对象是易变的），使Manager对象依赖于这个抽象，这样，以后扩展新的基于这个抽象的实现就会easy了。而manager里通过抽象的克隆创建需要数量的对象。这样，manager只依赖抽象。我想这也是我们提倡面向接口编程的原因。

总之，创建型模式解决了软件设计中对象创建的问题，通常，往往是我们遇到了易变类，才会使用创建型模式，至于使用哪种，就要看易变类和系统的特性了。

欢迎大家拍砖。我知道这文章简单浅显，只希望牛人飘过不留痕，菜鸟飞过有收获。

经我研究发现,原来,在我们安装vs2005时,系统自动安装了一个sql server 2005 express,而在安装sql server 2005时,系统检查到已经安装了workstation,所以就不再装了.

那怎么解决呢?最好的解决办法就是在安装vs2005时不要安装sql server 2005 express

如果已经装完了，那么最后用如下解决办法

     在控制面版中更改sql server 安装,把最后那个项(好象是workstation组建)干掉,然后再安装一遍工具下面的setup.exe

     如果还有问题,给我留言啊

补充一下,在干掉了最后那个组件后我发现了个问题，各种service都不不见了。只好又再重新装一次实例，当然，这可比整个sqlserver都重新装可省好多时间了。

不知道是我在第一次装的时候就忘了装service了还是卸载workstation时给卸掉了

          一直觉得设计模式是非常抽象的（事实上MS也是。。。），所以就想把它说的白话点儿，让人更容易理解。

          关于抽象工厂（Abstract Factory)模式，网上一个非常流行的例子，麦当劳和肯德基的故事。具体怎么说的我已经忘了，但是我想自己描述一遍，希望能让自己加深对设计模式思想的理解，也希望对大家有所帮助。

           既然叫抽象工厂，那一定有工厂（废话）。那么我们可以认为麦当劳和肯德基就是生产食物的工厂，那么理所当然，汉堡和鸡腿是他们共同生产的两种食物，不管你去MDL还是KDJ，说：我要鸡腿，那肯定不会给你拿来烤羊腿。嘿嘿 。这里，我们假定麦当劳和肯德基只生产这两种产品（这很重要，因为抽象工厂模式的一个很重要的场景就是产品相对稳定，如果要经常新增新产品，那么需要和另外的设计模式混合使用或寻求其它解决方案，这里不赘述）。

           情况已经很明显了，我们是消费者，我们就是客户，就是产品的消费者，就是程序中对象的调用者。而麦当劳和肯德基，理所当然的，他们就是工厂，一个叫做麦当劳工厂，一个叫做肯德基工厂，他们是真正的生产者，而对于我们这些客户消费者（程序中对象的调用者）来说，不管是去麦当劳还是肯德基，我们都说一样的话（我们的要求是稳定的）：我要鸡腿。只要我们提出这个请求，那么肯定会得到我们想要的。而作为工厂（生产者），麦当劳和肯德基都生产鸡腿和汉堡，所以抽象出来的抽象工厂都具有生产鸡腿和生产汉堡的功能，这是接口中的两个方法。因为在这个接口中，还不知道到底要生产谁家的产品，所以只能返回个抽象的鸡腿或汉堡，等到麦当劳或者肯德基工厂生产出来，就知道是谁家的了。（有标志嘛，哈哈，这就是动态创建对象）

            不管是麦当劳还是肯德基的鸡腿或汉堡，它的本质都是鸡腿或汉堡，所以可以抽象出来。那么鸡腿就派生出麦当劳的鸡腿和肯德基的鸡腿，而汉堡就派生出麦当劳的汉堡和肯德基的汉堡。而对于我们这些客户消费者（程序中对象的调用者）来说，不管是去麦当劳还使肯德基，我们都说一样的话（我们的要求是稳定的）：我要鸡腿。只要我们提出这个要求，那么肯定会得到我们想要的。不管是谁家的鸡腿，肯定是鸡腿不会是羊腿。所以，我们只要规定好是鸡腿（接口）就行了，而让工厂去绝对具体的制作过程。我们只伸手接过来一个鸡腿，狠狠的咬一口，恩，真香~：）

            到现在为止，我们只和鸡腿（抽象的接口）还有抽象工厂（因为我们不管是麦当劳还是肯德基，我们只要鸡腿）打交道。

            当我们走向一个快餐店，这个过程就决定了我们到底要哪个工厂来生产鸡腿和汉堡。我们可以把我们消费的习惯存入大脑，每次出门直接取出来，就只管走就行了。也不用看到底是走向了哪里，反正最后吃了好多鸡腿和汉堡，饱饱的走了。：）哈哈   理论讲解完毕，那么现在看看UML图。

        那么，现在，大家应该已经看清楚。这张图是我自己随手画的，画完之后发现，哇，这不就是经典的AbstractFactory模式的那张图吗？现在，你了解吗？

        必胜客来了，也做汉堡和鸡腿。那么怎么办呢？非常容易，我们消费者根本不管这些，只管把必胜客加入我们的大脑（配置文件），需要的时候，直接走进去就行了。仅仅需要添加一个必胜客工厂，必胜客汉堡，必胜客鸡腿，OK，一切搞定。那么又有人问了，我要喝汽水怎么办呢？我偷偷告诉你，这里不卖~：）哈哈，希望大家学习愉快，工作愉快

因为以前做过一段时间reporting service,一直觉得自己的sql 语句已经炉火纯青了，今天大挫。

一个很简单的东西，让我想了一个上午。

当需要批量更新某现存表的某个字段时，咱们办呢，我开始以为很简单，拿到手中一做，问题一大堆。

出了问题不是重点，重点是我对待问题的态度是不对的，所以要记录下来，以备将来反省。

人应该谦虚，不能骄傲，有点儿成就就不知道天高地厚了，以为天老大地老二我老三了。必要的自我激励是需要的，但也要避免使自己陷入自大的误区。

要时刻提醒自己我是最好的，心理同时也要时刻警醒自己不能自大，还有很多东西要学。

最后，把这个小问题贴出来：

Code
UPDATE table1
SET Col=t2.ColValue 
from table1
inner join  (select table2.idkey,table2.ColValue
     from table2) t2 
on table1.idkey = t2.idkey

 

 

在一个人的创业路程中，我们会有很多成就，如何对待这些成就，是值得注意的问题。

 

    我们得肯定它。因为肯定了自己，才会更加自信，才有信心有动力去迎接更大的挑战。但是同时，要提醒自己，这仅仅是个开始，还有很多事情要做，路还很

 

长。避免自己陷入安逸的状况，自大自满是前进中最大的阻力。这其实是个小问题，也因此没人去注意它。一旦没有注意调整心态，有可能改变很多事情，要是知道

 

创业路途遥远，我们需要尽量使自己少犯小错误，不犯大错误。心态很大程度上影响着人的决断。可能因为一时的意气风发，发起一个不充分的战斗；可能因为一时

 

的沮丧，丧失一个绝好的商业机会。

 

        血色浪漫大家看了，也知道，“胸有激雷而面如平湖者，可拜上将军”。

我认为一个合格的项目经理在项目管理过程中应该主要关注以下几方面的东西：

1，以验收项目为目的。所以，一切都应该是可验证的。把项目划分为若干个任务的同时，也应该已经为这些任务制定好了完成的标准，即做到什么程度为止。

    我们做项目，为的是什么？你要非说我为社会主义祖国信息化建设做出贡献我也不反对，但是我要说，如果最后不能验收，或者验收过程出现问题，那么项目就要面临失败了，项目经理就要面临走人了。所以，制定项目计划时，划分任务和制定任务的完成标准一样重要，这些标准可以是一些测试用例，也可以是其它一些可度量的标准。我还想说，要尽量给客户灌输一种标准：“验收就是跑完客户已经签字的测试用例，系统出现的错误在可以接受的范围”。

2，全员参与。作为一个新手项目经理，不可避免的会出现一些判断失误或者理解错误。怎么才能最大程度减少项目的风险呢？我的想法是如果是项目组比较小，则可以全员参与项目需求的分析和计划的讨论；如果项目组较大，则可以采取分组和骨干讨论的办法。在得到项目组成员的建议以后，项目经理更容易全面的思考，掌控项目的每一个风险，再独力做出项目计划并提交领导供审核。在这个过程中，项目组成员得以参与，提高了团队的凝聚力和主人翁意识，提高了开发的积极性；同时也是一次学习，对项目组成员的提高又莫大的好处。但是，全员参与有些问题不得不注意，在讨论过程中，项目经理应尽量避免发表意见，只应多意见提得好的组员予以鼓励，避免陷入无谓的争吵。总之，我认为，全员参与的项目管理有利于减小风险，提高项目成员的积极性和全局观，对项目成功有重大作用。

3，沟通。沟通是个谈不完的话题，项目经理的绝大多数难题都可以通过沟通来解决，所以沟通是重中之重。和项目组沟通，确保计划的按期执行，了解项目组成员的困难（包括日常生活上的困惑，这也会影响到项目），协调和组织资源；和领导沟通，让他知道你在干什么，都干了什么，将要干什么。领导和客户一样非常重要，因为他发工资！~_~ 和客户沟通，尽可能的去勾引它说出真正的想法，使项目的开发运行在正确的轨道。总之，沟通比任何事情都重要。

4，客户管理。我已经看到臭鸡蛋飞过来了，你个小小的项目经理，还是初级的，客户会归你管吗？确实是这样，客户怎么会归项目经理管呢。在我经历的一个外包项目中，那个客户甚至自己雇佣项目经理，来管理我们当时的开发团队进行工作。但是，我们不能放弃，明知山有虎，偏向虎山行。不屈不挠不怕斗争才是我们新世纪大好青年的本色。。。（省略5000字），那么，怎么斗争呢？我认为，只要仔细的想，办法还是有的。首先，要和客户明确需求，避免无意义的变更。从项目开始的那天起，凡是重要的与需求相关的文档，都要客户签字确认。这样能避免客户拍大腿出需求，那样会累死我们，还不讨好。当客户需要签自己名字的时候，一般它就会仔细思考一下，这样就能省去很多不必要的反复。其次，要让客户的工作计划中有你的项目。否则你发出的request不能及时得到回复，那么，项目延期是必然的。

最后，要经常保持沟通，让客户了解你的进展。他非常的希望也非常的愿意知道你在干什么，干到什么程度了，将要怎么干，否则他付钱也不心甘情愿。当然，我们也不能什么都跟客户说阿，挑些客户容易理解的，重点关键的"点"，以及项目需求模糊的地方。这样能最大程度上给客户一种安全感，也能尽快明确需求，引导客户说出真正想要的东西。

5，项目成员的培养。作为一个新手项目来说，我们可能没有太多的东西去教给项目组成员，甚至有些成员在技术上要比我们厉害得多。但是，我们可以为项目组成员提供一个成长和学习的机会，同时也是我们自己的学习机会。利用一切会议，讨论甚至吃饭，让项目组成员参与到项目中来，让他们了解整个项目，培养一种学习的氛围。我始终认为，相对于技术能力来说，一个程序员对项目的理解更为重要一些，理解的越好，对项目的贡献就越大。而学习是一个个人或者一个组织优秀或者将要走向优秀的基本特征。在项目组成员能力提高的同时，我相信项目的成功就在眼前。

最后，我想说的是，做正确的事情永远都比正确的做事情重要。这是我的座右铭。预祝所有的新手项目经理都能达到公司要求，满足客户期望，带领项目组成员共同前进。

第一种主要靠设置单元格的Navigation属性里的HaperLInk action,太简单我就不详细说了。

第二种主要靠设置组的Visibility属性,Init Visibility为hidden,by another item选为依赖项,就OK了。

忘了说了还有种就是把子报表直接加到父报表中.也挺简单的，大家研究一下就OK了。

/**//// <summary>
        /// 发送邮件
        /// </summary>
        internal void Send()
        {
            System.Web.Mail.MailMessage mailmessage = new MailMessage();

            mailmessage.From = "fmzzs@126.com";
            mailmessage.To = "张大伟";
            mailmessage.Subject = "我是主题";
            mailmessage.Body = "我是内容";
            mailmessage.Cc = "张明";


            mailmessage.Fields.Add("http://schemas.microsoft.com/cdo/configuration/smtpauthenticate", "1");

            mailmessage.Fields.Add
            ("http://schemas.microsoft.com/cdo/configuration/sendusername",myEmailUserName);
            //自己邮箱的用户名 
            mailmessage.Fields.Add("http://schemas.microsoft.com/cdo/configuration/sendpassword", myEmailPassword);
            //自己邮箱的密码 
            System.Web.Mail.SmtpMail.SmtpServer ="smtp.126.com"; //SMTP Server
            System.Web.Mail.SmtpMail.Send(mailmessage);

        }

这个方法发送邮件有点儿老了，dotnet 2.0 的System.Net空间下有新的发送方式，因为着急,所以没看.这个就当是学习笔记了，下次再研究新的。