博客园_hq_space - Live and Learn

12个项目管理成功的关键原则

2011-06-04T03:30:00Z

12个项目管理成功的关键原则

1、项目经理必须关注项目成功的三个标准

简单地说，一是准时;二是预算控制在既定的范围内;三是质量得到经理和用户们的赞许。项目经理必须保证项目小组的每一位成员都能对照上面三个标准来进行工作。

2、任何事都应当先规划再执行

就项目管理而言，很多专家和实践人员都同意这样一个观点：需要项目经理投入的最重要的一件事就是规划。只有详细而系统的由项目小组成员参与的规划才是项目成功的唯一基础。当现实的世界出现了一种不适于计划生存的环境时，项目经理应制定一个新的计划来反映环境的变化。规划、规划、再规划就是项目经理的一种生活方式。

3、项目经理必须以自己的实际行动向项目小组成员传递一种紧迫感

由于项目在时间、资源和经费上都是有限的，项目最终必须完成。但项目小组成员大多有自己的爱好，项目经理应让项目小组成员始终关注项目的目标和截止期限。例如，可以定期检查，可以召开例会，可以制作一些提醒的标志置于项目的场所。

4、成功的项目应使用一种可以度量且被证实的项目生命周期

标准的信息系统开发模型可以保证专业标准和成功的经验能够融入项目计划。这类模型不仅可以保证质量，还可以使重复劳动降到最低程度。因此，当遇到时间和预算压力需要削减项目时，项目经理应确定一种最佳的项目生命周期。

5、所有项目目标和项目活动必须生动形象地得以交流和沟通

项目经理和项目小组在项目开始时就应当形象化地描述项目的最终目标，以确保与项目有关的每一个人都能记住。项目成本的各个细节都应当清楚、明确、毫不含糊，并确保每个人对此都达成了一致的意见。

6、采用渐进的方式逐步实现目标

如果试图同时完成所有的项目目标，只会造成重复劳动，既浪费时间又浪费钱。俗话说，一口吃不成个胖子。项目目标只能一点一点地去实现，并且每实现一个目标就进行一次评估，确保整个项目能得以控制。

7、项目应得到明确的许可，并由投资方签字实施

在实现项目目标的过程中获得明确的许可是非常重要的。应将投资方的签字批准视为项目的一个出发点。道理很简单：任何有权拒绝或有权修改项目目标的人都应当在项目启动时审查和批准这些项目目标。

8、要想获得项目成功必须对项目目标进行透彻的分析

研究表明，如果按照众所周知记录在案的业务需求来设计项目的目标，则该项目多半会成功。所以，项目经理应当坚持这样一个原则，即在组织机构启动项目之前，就应当为该项目在业务需求中找到充分的依据。

9、项目经理应当责权对等

项目经理应当对项目的结果负责，这一点并不过分。但与此相对应，项目经理也应被授予足够的权利以承担相应的责任。在某些时候，权利显得特别重要，如获取或协调资源，要求得到有关的中小企业的配合，做相应的对项目成功有价值的决策等等。

10、项目投资方和用户应当主动介入，不能被动地坐享其成

多数项目投资方和用户都能正确地要求和行使批准(全部或部分)项目目标的权力。但伴随这个权力的是相应的责任——主动地介入项目的各个阶段。例如，在项目早期要帮助确定项目目标;在项目进行中，要对完成的阶段性目标进行评估，以确保项目能顺利进行。项目投资方应帮助项目经理去访问有关的中小企业和目标顾客的成员，并帮助项目经理获得必要的文件资料。

11、项目的实施应当采用市场运作机制

在多数情况下，项目经理应将自己看成是卖主，以督促自己完成投资方和用户交付的任务。项目计划一旦批准项目经理应当定期提醒项目小组成员该项目必须满足的业务需求是什么，以及该怎样工作才能满足这些业务需求。

12、项目经理应当获得项目小组成员的最佳人选

最佳人选是指受过相应的技能培训，有经验，素质高。对于项目来说，获得最佳人选往往能弥补时间、经费或其它方面的不足。项目经理应当为这些最佳的项目成员创造良好的工作环境，如帮助他们免受外部干扰，帮助他们获得必要的工具和条件以发挥他们的才能。
本文链接

领域驱动设计下系统层次结构风格

2010-12-09T16:25:00Z

传统的三层架构

最简单的分层方式自然就是“表现层、业务逻辑层和数据访问层”，我们可以用下图来表示这个思想：

注意图中打虚线的“基础结构层”，从实践的表现上来看，这部分内容可能就是一些帮助类，比如 SQLHelper之类的，也可能是一些工具类，比如TextUtility之类。这些东西可以被其它各层所访问。而基于分层的概念，表现层只能跟业务逻辑层打交道，而业务逻辑层在数据持久化方面的操作，则依赖于数据访问层。表现层对数据访问层的内容一无所知。

从领域驱动的角度看，这种分层的方式有一定的弊端。首先，为各个层面提供服务的“基础结构层”的职责比较紊乱，它可以是纯粹的技术框架，也可以包含或处理一定的业务逻辑，这样一来，业务逻辑层与“基础结构层”之间就会存在依赖关系；其次，这种结构过分地突出了“数据访问”的地位，把“数据访问”与 “业务逻辑”放在了等同的地位，这也难怪很多软件人员一上来就问：“我的数据表该如何设计？”

领域驱动设计的分层

领域驱动设计将软件系统分为四层：基础结构层、领域层、应用层和表现层。与上述的三层相比，数据访问层已经不在了，它被移到基础结构层了。

基础结构层：该层专为其它各层提供技术框架支持。注意，这部分内容不会涉及任何业务知识。众所周知的数据访问的内容，也被放在了该层当中，因为数据的读写是业务无关的
领域层：包含了业务所涉及的领域对象（实体、值对象）、领域服务以及它们之间的关系。这部分内容的具体表现形式就是领域模型（Domain Model）。领域驱动设计提倡富领域模型，即尽量将业务逻辑归属到领域对象上，实在无法归属的部分则以领域服务的形式进行定义。有关领域对象和领域服务的内容，
应用层：该层不包含任何领域逻辑，但它会对任务进行协调，并可以维护应用程序的状态，因此，它更注重流程性的东西。在某些领域驱动设计的实践中，也会将其称为“工作流层”。应用层是领域驱动中最有争议的一个层次，也会有很多人对其职责感到模糊不清。比如，有些国外的开发人员会觉得，既然不包含领域逻辑，那又如何协调工作任务呢？
表现层：这个好理解，跟三层里的表现层意思差不多，但请注意，“Web服务”虽然是服务，但它是表现层的东西(ExtJS框架+Asp.net MVC框架)

从上图还可以看到，表现层与应用层之间是通过数据传输对象（DTO）进行交互的，数据传输对象是没有行为的POCO对象，它的目的只是为了对领域对象进行数据封装，实现层与层之间的数据传递。为何不能直接将领域对象用于数据传递？因为领域对象更注重领域，而DTO更注重数据。不仅如此，由于“富领域模型”的特点，这样做会直接将领域对象的行为暴露给表现层

系统结构

由于是领域驱动设计，本案例系统分层与传统分层略有不同。分为四层：展现层、应用服务层、领域层和基础结构层。展现层采用ASP.NET MVC框架实现；应用服务层则是一个WCF Service；领域层采用Entity Framework结合领域接口；基础结构层则为整个应用提供了IoC、Caching、Specifications、Repository等的具体实现。整个系统架构基本上可以以下图描述：

需要说明的是，在上图中的Domain Model和EdmRepository之间出现了双向依赖。其实，Domain Model只依赖于仓储（Repository）的接口，而EdmRepository是基于Entity Framework的一种仓储实现方式，它实现IRepository接口，同时也对Domain Model产生依赖，以获得对聚合根的访问。关键的一步在于，EnterpriseLibrary Library采用依赖注入，将EdmRepository注射到Domain Model中，于是，Domain Model根本不依赖于仓储的具体实现方式，保证了领域模型层面的纯净度。

仓储的实现可以用下图表述：

从本文还可以了解到，依赖注入是维持领域模型纯净度的一大利器；另一大利器是领域事件，我将在后续的文章中详述。对于本文开始的第三个问题，也就是仓储实现的可扩展性，将在下篇文章中进行讨论，包括的内容有：事务处理和可扩展的仓储框架的实现。

在面向对象的程序中，用户界面(UI)、数据库和其他支持代码，经常被直接写到业务对象中去。在UI和数据库脚本的行为中嵌入额外的业务逻辑。出现这种情况是因为层短期的观点看，它是使系统运行起来的最容易的方式。

当与领域相关的代码和大量的其他代码混在一起时，就很难阅读并理解了。对UI的简单改动就会改变业务逻辑。改变业务规则可能需要小心翼翼地跟踪UI 代码、数据库代码或者其他的程序元素。实现一致的模型驱动对象变都不切实际，而且自动化测试也难已使用.如果在程序的每一个行为中包括了所有的技术和逻辑，那么它必须很简单，否则会难以理解。

用户界面层	负责向用户显示信息，并且解析用户命令。外部的执行者有时可能会是其他的计算机系统，不一定非是人
应用层	定义软件可以完成的工作，并且指挥具有丰富含义的领域对象来解决问题。这个层附负责的任务对业务影响深远，对跟其他系统的应用层进行交互非常必要。这个层要保存简练。它不包括处理业务规则或知识。只是给下一层中相互协作的领域对象协调任务、委托工作。在这个层次中不反映业务情况的状态，但反映用户或程序的任务进度的状态
领域层	负责表示业务概念、业务状况的信息以及业务规则。尽管保存这些内容的技术细节由基础结构层兰完成。反映业务在的状态在该层中被控制和使用。这一层是业务软件的核心
基础结构层	为上册提供通用的技术能力；应用的消息发送、领域持久化，为用户加盟绘制窗口等。提供架构框架，基本结构层还可以支持这四层之间的交互模式

在一个复杂的程序进行层次划分。为每一层进行设计，每层都是内聚的而且只依赖于它的下层。采的用标准的架构模式来完成与上层松散关联。将所有与领域模型相关的代码集中在一层，并且家它与用户界面层、应用层和基础结构层的代码分离。领域对象可以将重点放在表达领域模型上，不需要关心他们自己的显示、存储和管理应用任务等内容。这样使模型发展得足够丰富和清晰，足以抓住本质的业务知识并实现它。

项目管理过程之项目团队

2010-08-26T07:22:00Z

项目管理过程之项目团队

      对于以项目为基本运作单位的公司来说，“项目组”具有相当的独立性，是典型意义上的团队。团队有两个鲜明的特点：第一是个体成员有共同的工作目标；第二是成员需要协同工作，也就是说某个成员工作需要依赖于另一成员的结果。举个简单的例子，如果用照相机拍完一张照片，你无法说清拍这张照片是镜头的功劳，还是暗箱、快门、胶卷的功劳，其实，这些部件的工作能力必须通过一个整体表现出来，这个整体就像是团队。另外需要注意的是，这种协同工作产生的整体效力无法通过数量的叠加形成。

    在IT项目中，团队建设的意义重大。虽然一个企业可以通过各种方式获得各种优秀人才，但能否让他们协同工作就难说了。正所谓“获得优秀的球员容易，但让他们一起打球就很难了（Casey Stengel）”。在失败的项目中，团队分裂因素占相当的比例。

    团队工作的方式有明显的特点，就像驾船向目标远航的过程：首先，帆船每次出航都有明确的目的；其次，一艘船只能装载一定的资源，续航能力有限，必须在限定的约束内完成目标；第三，一艘船上的船员分工明确、专人专岗，岗位难以相互替换；第四，在大海中航行的帆船要独立应对各种情况，独立分析判断并做出决策；第五，如果能到达目的地，是所有船员的功劳，而一旦航行失败，没有一个船员会单独获得荣誉。

    成功团队会具有一些共同的特点：首先是团队的目标明确，成员清楚自己工作对目标的贡献；第二，团队的组织结构清晰，岗位明确；第三，有成文或习惯的工作流程和方法，而且流程简明有效；第四，项目经理对团队成员有明确的考核和评价标准，工作结果公正公开、赏罚分明；第五，组织纪律性，这点往往容易被忽略。违反纪律往往会牺牲多数人的利益，因此“以人为本”绝不是“以个人为本”；第六，相互信任，善于总结和学习。

    优秀团队的建设并非一蹴而就，要经历几个阶段。第一个阶段称为形成期（Forming），团队中的个体成员转变为团队成员，开始形成共同目标；团队往往会沉浸在对未来的美好期待中。第二个阶段称为震荡期（Storming），团队成员开始执行分配的任务，一般会遇到超出预想的困难，希望被现实打破，个体之间开始争执，互相指责，并且开始怀疑项目经理的能力。第三个阶段称为正规期（Norming），经过一定时间的磨合，团队成员之间相互熟悉和了解，矛盾基本解决，项目经理能够确立正确的关系。第四个阶段称为表现期（Performing），随着相互之间的配合默契和对项目经理信任，成员积极工作，努力实现目标。这时集体荣誉感非常强，常将团队换成第一称谓，如“我们那个组”“我们部门”等，并会努力捍卫团队声誉。

    在建设团队的各个阶段中，一些必要的团队建设方法非常重要。这里介绍一些实用方法：

挑选骨干

    “一个好汉三个帮”，如果没有几个核心骨干，一个项目经理难以管理众多人员。骨干成员与基本成员的重要区别是：基本成员要求合理物质回报和良好文化氛围，而骨干成员往往认识到机会的重要性，认为成功比金钱重要。

沟通渠道

    一个团队不仅需要工作上的沟通，还需要一些“生活”上的沟通，这可以帮助大家建立信任和友情，在工作中能起促进作用。可以采用的方法包括每天与不同的人吃工作午餐；还可以在周末组织大家一起吃晚餐，逐步建立开诚布公的良好文化氛围。

地理集中

    中的环境下一起工作对团队建设的作用决不可忽视。大家可以经常交流工作和个人情况，避免“我们”对“他们”以及团队的分裂成小团体的情况发生。

注意心理疲劳

    的工作强度一般都比较大，为了进度往往连续加班，在这种情况下，更要注意工作的阶段性和节奏性。可以在取得阶段性目标的情况下举行庆祝活动，并让每个人参加，让大家适度放松并建立信心。

团队会议

    不同于工作会议，一种是讨论团队工作中存在哪些问题以及如何改进，项目经理不是下结论的人，而是寻求答案的人。另一种是帮助某个成员进行改进。第二种会议可以先让被讨论的对象回避，自己写评语，同时大家写对他的评语。然后对比双方的差异，找出问题所在以求不断改进。

评价成员

    成员在完成委派的任务后都非常期待着评价。评价可以是正向的也可以是负面的。一般都可以表扬、提醒、批评和处罚。表扬和批评最好公开公正，否则达不到鼓励先进、鞭策后进的作用。对工作中出现的过失、或因事先没有约定造成的问题，应该考虑先提醒。提醒要隐蔽，让成员知道错误和后果，并承诺不再犯错。处罚是万不得以的措施，处罚不是惩罚：惩罚是报复性措施，有感情色彩和 “摆平”的意思，而处罚是中性处理措施，不涉及人身攻击，且被处罚的人事先知道这是自己行为的结果。

解决冲突

   好的团队是“打出来的，不是练出来的！” ，在巨大的工作压力下冲突在所难免。冲突的益处是暴露问题，激起讨论，澄清思想或寻求新的方案；害处是控制不好就会破坏沟通、破坏团结、降低信任。正确解决冲突首先要营造氛围，控制情绪，建立友善信任的环境；其次要正视问题，换位思考，愿意倾听别人的意见；第三，要积极沟通，交换意见，寻找分歧；第四，要肯放弃原来观点并重新考虑问题；第五，力争达成一致，尽力得到最好和最全面的方案。
总之，团队建设非常重要。但这不仅仅是一个团队的事，还与企业文化密切相关，而企业文化则需要一定时间进行积累和沉淀。

德鲁克之沟通的四原则

2010-07-25T13:55:00Z

第一个就抓到了沟通是一种感知，什么叫感知呢？意思是按照对方的经验或能接纳的语言表达。

譬如说是一个小孩子，你一定要用小孩子的方式跟他沟通，你不能说你是大人用大人的方式，他是小孩无法沟通。假设他是一个木匠，要跟他沟通一定要懂得木匠的语言跟他沟通，刚才讲他的身份是校长，校长是学校里面微笑的长辈，意思是说他是一个校长，这个校长本身你必须要懂得他的语言，这个是感知，感知是根据他的感觉，根据他的经验来表达，来传送你的信息。

第二个把握的原则就是，要根据对方的期望。

而不是想要表达我要卖什么，我要讲什么，不是，而是对方的价值观是什么？他期待什么？他需求什么？他不要什么？他讨厌什么？这个时候我们越来越清楚，原来我们要提供的是他能够接纳的，他想要的，这个时候期望可以得到满足。

第三个原则是，必须在沟通里面造成要求，提出要求。

意思是我沟通我要传达信息给你，我是一个老总，我要把我的意念、我的想法告诉你，你去完成任务。这个时候你也必须用他的语言，用属下能够听得懂的语言，不打官腔，清楚的把所有该讲的话，透过你的描述，透过他的价值观，期望能够和公司的价值观吻合，能够跟所达成的目的吻合，这样皆大欢喜，他要达成目的公司也很棒，他也很愿意，这样双赢。

第四个沟通和资讯往往是对立，但往往是关联的。因为沟通是一种经验，而资讯刚好是一种逻辑，

逻辑是有编码的，但是接收者必须要解码。比如我发一个简讯给你，他说没收到或收到之后没讲清楚，这叫解码。任何东西都要解码，教科书里面我们要解码，没有解码我们不明白什么意思，所以才要老师带。
这个时候我们必须要晓得，所有沟通最棒的沟通第一个叫经验沟通，经验分享。第二个沟通叫做所谓的现身说法。优米网就刚好提供了一个这样的平台，它既有感知、期望，然后还有一个能够达到年轻人一同成长这样的欲望、这样的要求。那么另外它还透过所谓的网络，然后让大家能够看得到，时间还可以停留，然后你可以来，不会像看电视，看完了我因为没有把它录下来，它这个可以时时刻刻重复再重复。

Entity Framework级联更新

2010-06-29T05:55:00Z

首先來看一下示範資料庫的 ER-Model

User 使用者
Group 群組
UserDepartment 使用者部門

需求是要建立一個 User 包含 UserDepartment 以及 Group，
直接來看語法

方式一

`01`	`using` `(TestEntities te =` `new` `TestEntities())`

02 {

`03`	`////新增一個 User`

`04`	`User u =` `new` `User()`

05 {

`06`	`User_name =` `"David",`

`07`	`User_email =` `"asdtey@yahoo.com.tw",`

`08`	`////此為多對一時的新增方式`

`09`	`UserDepartment = te.UserDepartment.Where(a => a.UserDepartment_name ==` `"開發部").First()`

10 };

11

`12`	`////新增User屬於的群組`

13

`14`	`////先取得要新增的群組`

`15`	`Group g1 = te.Group.Where(a => a.Group_name ==` `"攝影社").First();`

`16`	`Group g2 = te.Group.Where(a => a.Group_name ==` `"開發二").First();`

`17`	`////多對多的新增方式`

`18`	`u.Group.Add(g1);`

`19`	`u.Group.Add(g2);`

20

`21`	`te.AddToUser(u);`

22

23 ////儲存

`24`	`te.SaveChanges();`

25 }

此方法可以順利新增一個 User 同時包含 UserDepartment 以及 Group，
不過有個問題是說仔細去看語法時，
會發現在新增之前會先去資料庫取得UserDepartment 以及 Group 的資料，才進行新增，
但我只是要新增 User ，並沒有要取得 UserDepartment 、 Group 的資料，
每次新增都先去資料庫撈資料，會影響效能，
這邊分享另一種寫法

方法二

01 ////方式二

`02`	`using` `(TestEntities te =` `new` `TestEntities())`

03 {

`04`	`////新增一個 User`

`05`	`User u =` `new` `User()`

06 {

`07`	`User_name =` `"David",`

`08`	`User_email =` `"asdtey@yahoo.com.tw",`

09 };

10

`11`	`////此為多對一時的新增方式`

`12`	`UserDepartment userDepartment =` `new` `UserDepartment()`

13 {

`14`	`EntityKey =` `new` `EntityKey("TestEntities.UserDepartment",` `"UserDepartment_id", 1),`

`15`	`UserDepartment_id = 1`

16 };

`17`	`te.Attach(userDepartment);`

`18`	`u.UserDepartment = userDepartment;`

19

`20`	`//////多對多的新增方式`

`21`	`Group g1 =` `new` `Group()`

22 {

`23`	`EntityKey =` `new` `EntityKey("TestEntities.Group",` `"Group_id", 1),`

`24`	`Group_id = 1`

25 };

`26`	`te.Attach(g1);`

`27`	`u.Group.Add(g1);`

28

`29`	`Group g2 =` `new` `Group()`

30 {

`31`	`EntityKey =` `new` `EntityKey("TestEntities.Group",` `"Group_id", 2),`

`32`	`Group_id = 2`

33 };

`34`	`te.Attach(g2);`

`35`	`u.Group.Add(g2);`

36

37 ////儲存

`38`	`te.AddToUser(u);`

`39`	`te.SaveChanges();`

40 }

此方法利用EntityKey讓ObjectContext知道我們要關聯的物件是甚麼，
就不會先去資料庫撈資料，提升效能，
但是缺點是要打的code變多了，也缺少IntelliSence

再分享一下，如果只要新增User以及UserDepartment(多對一關係)時，
還可以這樣寫，

方法三

01 ////方式三

`02`	`using` `(TestEntities te =` `new` `TestEntities())`

03 {

`04`	`////新增一個 User`

`05`	`User u =` `new` `User()`

06 {

`07`	`User_name =` `"David",`

`08`	`User_email =` `"asdtey@yahoo.com.tw",`

09 };

10

`11`	`u.UserDepartmentReference.EntityKey =` `new` `EntityKey("TestEntities.UserDepartment",` `"UserDepartment_id", 1);`

12

13 ////儲存

`14`	`te.AddToUser(u);`

`15`	`te.SaveChanges();`

16 }

建議在大量新增的時候可以使用方法二避免影響效能及資料庫

一樣先來看一下示範資料庫的 ER-Model

User 使用者
Group 群組
UserDepartment 使用者部門

需求是要修改 User的資料包含 UserDepartment 以及 Group，
直接來看語法

`01`	`using` `(TestEntities te =` `new` `TestEntities())`

02 {

`03`	`////取得 David 資料`

`04`	`var u = te.User.Where(a => a.User_name ==` `"David").First();`

`05`	`u.Group.Load();`

`06`	`u.UserDepartmentReference.Load();`

07

`08`	`////修改 Email`

`09`	`u.User_email =` `"asdtey@yahoo.com.tw";`

`10`	`te.SaveChanges();`

11

12

`13`	`//修改使用者部門`

14

`15`	`////先取得要變更成的部門`

`16`	`var t = te.UserDepartment.Where(a => a.UserDepartment_name ==` `"經理部").First();`

`17`	`////重新給予部門`

`18`	`u.UserDepartment = t;`

`19`	`te.SaveChanges();`

20

21

22 //修改群組

23

`24`	`////因為 User 與 Group 為多對多的關係`

`25`	`////因此修改方式為刪除與新增`

26

`27`	`////刪除群組`

`28`	`var g = u.Group.First();`

`29`	`u.Group.Remove(g);`

30

`31`	`////取得要新增的群組`

`32`	`var g1 = te.Group.Where(a => a.Group_name ==` `"電研社").First();`

`33`	`u.Group.Add(g1);`

34

`35`	`te.SaveChanges();`

36 }

修改部分比較簡單，下次來介紹刪除的部分

一樣先來看 ER-Model

需求是要刪除使用者(User)資料，
來看看範例

範例一

`01`	`////範例刪除 David 的資料`

`02`	`using` `(TestEntities te =` `new` `TestEntities())`

03 {

`04`	`////先取得 David 的資料`

`05`	`var u = te.User.Where(a => a.User_name ==` `"David").First();`

06

`07`	`////刪除 David`

`08`	`te.DeleteObject(u);`

09

`10`	`////儲存變更`

`11`	`te.SaveChanges();`

12 }

這段語法看起來正常，但是一執行卻發生

'/ADOEntityFrameworkDemo' 應用程式中發生伺服器錯誤。

The DELETE statement conflicted with the REFERENCE constraint "FK_UserGroup_User". The conflict occurred in database "Test", table "dbo.UserGroup", column 'UserGroup_userid'.
The statement has been terminated.

描述: 在執行目前 Web 要求的過程中發生未處理的例外情形。請檢閱堆疊追蹤以取得錯誤的詳細資訊，以及在程式碼中產生的位置。
例外詳細資訊: System.Data.SqlClient.SqlException: The DELETE statement conflicted with the REFERENCE constraint "FK_UserGroup_User". The conflict occurred in database "Test", table "dbo.UserGroup", column 'UserGroup_userid'.
The statement has been terminated.

@@ 原來是因為還有 Reference ，
再把語法修改一下

範例二

`01`	`////範例刪除 David 的資料`

`02`	`using` `(TestEntities te =` `new` `TestEntities())`

03 {

`04`	`////先取得 David 的資料`

`05`	`var u = te.User.Where(a => a.User_name ==` `"David").First();`

06

`07`	`////ADO.Net Framework 在刪除的時候，會連帶一起刪除關連的資料`

`08`	`////但是必須先載入關連的資料`

`09`	`u.Group.Load();`

`10`	`u.UserDepartmentReference.Load();`

11

`12`	`////刪除 David`

`13`	`te.DeleteObject(u);`

14

`15`	`////儲存變更`

`16`	`te.SaveChanges();`

17 }

這段語法就可以順利執行囉

說明一下，ADO.Net Entity Framework 在處理關聯式資料的時候，會把相關的所有資料一起刪除，
但是前提是在刪除前，必須先使用【Load】方法，把相關聯資料載入

OOAD & OOP

2010-05-28T09:31:00Z

一、面向对象技术基本概念
面向对象技术基于对象概念，以对象为中心，以类和继承为构造机制，充分利用接口和多态提供灵活性，来认识、理解、刻划客观世界和设计、构建相应的软件系统.

面向对象的特征

– 抽象，先不考虑细节
– 封装，隐藏内部实现
– 继承，复用现有代码
– 多态，改写对象行为

二、面向对象的设计目标
1、可扩展性Extensibility
–容易添加新的功能
2、灵活性Flexibility
–容易添加新的功能代码修改平稳地发生
3、可插入性Pluggability
–容易将一个类抽出去，同时将另一个有同样接口的类加入进来

三、面向对象设计基本的设计原则:
1、针对接口编程，而不是针对实现编程
– 客户无需知道所使用对象的特定类型，只需要知道对象拥有客户所期望的接口。
2、优先使用对象组合，而不是类继承
– 继承在某种程度上破坏了封装性，子类父类耦合度高；而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。
3、封装变化点
– 使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合。

四、面向对象的设计原则：

1、“开-闭”原则（Open-Closed Principle,OCP）封装的问题 - 对可变性封装
一个软件实体应当对扩展开放，对修改关闭。你添加新功能的时候应该只是向代码集中添加新的代码不应该修改原来的代码。

2、里氏代换原则（Liskov Substitution Principle, LSP）职责的问题 - 如何进行继承
LSP原则要求子类可以无条件的替代父类，子类不能对父类没有暴露的接口进行扩展，客户要调用功能只能通过父类暴露的接口来调用用不能擅自向子类调用。

3、依赖倒转原则（dependence inversion principle, DIP）耦合度问题 - 针对接口编程
依赖倒转原则就是要实现依赖于抽象，抽象不要依赖于实现。要针对接口编程，不要针对实现编程。

4、合成/聚合复用原则（Composite/Aggregate Reuse Principle或CARP）复用问题 - 尽量使用组合/聚合、尽量不使用继承
在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用这些对象的目的。

5、迪米特法则（Law of Demeter，LoD）耦合度问题 - 不要和陌生人说话
一个软件实体应当尽可能少的与其他实体发生相互作用。迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。

6、接口隔离原则（interface separate principle, ISP）职责单一 - 恰当的划分角色和接口
使用多个专门的接口比使用单一的总接口要好。也就是说，一个类对另外一个类的依赖性应当是建立在最小的接口上。

五、目标与原则的关系

可扩展性Extensibility
开/闭原则、里氏替换原则、依赖倒转原则、合成/聚合复用原则

灵活性Flexibility
开/闭原则、Demeter 法则、接口隔离原

可插入性Pluggability
开/闭原则、里氏代换原则、依赖倒转原则、合成/聚合复用原则

sql view

2010-04-11T08:52:00Z

//ServerA
Use pubs
go
Create table customers (
Customerid varchar(5) not null,
CompanyName varchar(50) not null,
ContactName varchar(30) null,

CONSTRAINT PK_customers PRIMARY KEY CLUSTERED (Customerid),
CONSTRAINT CK_customerid CHECK (Customerid between 'AAAAA' and 'LZZZZ')
)

//Server B
use pubs
go
Create table customers (
Customerid varchar(5) not null,
CompanyName varchar(50) not null,
ContactName varchar(30) null,
CONSTRAINT PK_customers PRIMARY KEY CLUSTERED (Customerid),
CONSTRAINT   CK_customerid   CHECK (Customerid between 'M' and 'ZZZZZ')
)
go
//ServerA
exec sp_addlinkedserver
       @server='DPVSERVER1', @srvproduct='',
       @provider='SQLOLEDB', @datasrc='ServerB'
go
exec sp_addlinkedsrvlogin
@rmtsrvname = 'DPVSERVER1'
     , @useself = 'false'
     , @rmtuser = 'sa'
     , @rmtpassword = 'password'
go
//ServerB
exec sp_addlinkedserver
       @server='DPVSERVER2', @srvproduct='',
       @provider='SQLOLEDB', @datasrc='ServerA'
exec sp_addlinkedsrvlogin
@rmtsrvname = 'DPVSERVER2'
     , @useself = 'false'
     , @rmtuser = 'sa'
     , @rmtpassword = 'password'
go
//ServerA
Exec sp_serveroption 'DPVSERVER1', 'lazy schema validation', 'true'
//Sever B
Exec sp_serveroption 'DPVSERVER2', 'lazy schema validation', 'true'

//Server A：
Create view DPV_Customers As
   Select * from Customers
   Union all
   Select * from DPVSERVER1.Pubs.dbo.Customers
//Server B
   Create view DPV_Customers As
   Select * from DPVSERVER2.Pubs.dbo.Customers
   UNION ALL
   Select * from Customers

set xact_abort on
INSERT INTO DPV_CUSTOMERS VALUES('AAMAY','FUZHOU COMPANY','MARRY')
INSERT INTO DPV_CUSTOMERS VALUES('CJOHN','XIMEN COMPANY','MARRY')
INSERT INTO DPV_CUSTOMERS VALUES('SMITH','SHANGHAI COMPANY','TOM')
INSERT INTO DPV_CUSTOMERS VALUES('YOUNG','FUJIAN COMPANY','JANE')
INSERT INTO DPV_CUSTOMERS VALUES('GTOPP','BEJING COMPANY','TOM')
INSERT INTO DPV_CUSTOMERS VALUES('QUILH','BEJING COMPANY','TOM')

//SELECT * FROM DPV_Customers order by customerid

//SELECT * FROM DPV_Customers WHERE CustomerID= 'QUILH'

sql2005:

alter database adventureWorks add filegroup [fg1]
go
alter database adventureWorks add filegroup [fg2]
go
alter database adventureWorks add filegroup [fg3]
go
alter database adventureWorks
add file
(name='fg1',
filename='c:\fg1.ndf',
size=5mb)
to filegroup [fg1]
go
alter database adventureWorks
add file
(name='fg2',
filename='d:\fg2.ndf',
size=5mb)
to filegroup [fg2]
go
alter database adventureWorks
add file
(name='fg3',
filename='e:\fg3.ndf',
size=5mb)
to filegroup [fg3]
go
use adventureWorks
go
Create partition function emailPF(nvarchar(50)) as range right for values ('G','N')
go
Create partition scheme emailPS as partition emailPF to (fg1,fg2,fg3)
go
Create table customermail (custid int, email nvarchar(50)) on emailPS(email)
go

唐僧为什么可以领导孙悟空

2010-03-30T14:31:00Z

小时候读西游记总有一个疑问——那个唐僧那么无能，为什么孙悟空非要带着他去取经呢？如果孙悟空自己去取经，不就麻烦少多了么？后来长大了，工作了，先被人领导，之后又领导别人，总算明白了，原来唐僧领导孙悟空是有道理的，如果不是这样，取经这项伟大的事业就不能成功了。唐僧究竟有什么东西，是孙悟空没有的呢？究竟是什么因素让唐僧是一个领导，而孙悟空只是一个打工者呢
1. “崇高信念”
　　第一个东西，唐僧有，而孙悟空没有的是“崇高信念”。唐僧在自己的崇高信念面前，丢掉性命都不会眨眼，而孙悟空就不会了，他能力很强，但是他没有坚定不移的信念，多次打退堂鼓。没有信念的人，就不能给别人以信心，就不能给别人以动力，遇到困难就容易退缩，领导者都胆怯了，退缩了，团队就会散掉；而信念不够崇高也不行，自私自利的信念，小富即安的信念，都让别人离你而去。我们对比一下水浒里的宋江，一个没有崇高信念的人，最后被招安了，他的最高理想就是这样，所以他就葬送了他的团队。
　　现在有些企业家总是抱怨员工忠诚度不足，刚刚学会点业务，就跳槽了，刚刚结交几个客户，就自己去开公司了。这当然有社会的因素，有员工本身的原因，但是企业家也要自己检讨一下自己，你自己是否有崇高的信念。一个企业的终极目标是为老板创造更多的利润，并留下最多的钱给他的子女；而另一个企业的终极目标是为社会提供更加优质的产品和服务，企业家更是在去世之后把多数个人财产捐给社会；请问哪一个更配拥有忠诚的员工？
　　2. “无能”也是一种领导者的财富
　　第二个东西，唐僧有，而孙悟空没有的是“无能”。“无能”也是一种领导者的财富！唐僧那么无能，于是他就会欣赏有本事的人，能够包容能人们的其他缺点，才能找到三个有本事的徒弟来保护自己。如果唐僧神通广大，孙悟空就不会愿意跟着他了，正是因为唐僧无能，所以孙悟空就有了用武之地，就使得他可以充分实现自己的价值。
　　我们看看能力很强的孙悟空，他本人在花果山的徒子徒孙，全部都是饭桶，没有一个有用的。他本事太大，他就瞧不起其他有本事的人，于是其他有本事的人就不喜欢跟着他。他自己太强，他的团队就变成一群饭桶。西游记有一章，孙悟空和唐僧闹翻了，自己搞了一个假团队打算去取经——幸好没去，要不然见到厉害的妖怪，把孙悟空捉住，谁去救他呢？谁去搬救兵呢？他自己的团队都是饭桶，只好看着自己的领导送死。而唐僧就不会，别看他什么都不会，但是他却很安全。当年司马懿抓住蜀国的小兵，问他诸葛亮每天都干些什么，小兵想这个不算情报吧，就说丞相凡是责罚20杖以上的军法事宜，都要亲自监督。司马懿就知道了，诸葛亮肯定会被累死。——太能干的领导，敌人没来，自己就累死了，而唐僧这个无能的长生肉，却还能一直很安全。
中国很多企业都有一个非常能干的老板，同时带着一群饭桶员工。开始创业的时候，为了生存，可能是必须的，但是一旦生存问题解决了，企业家就要考虑怎么给员工搭建让他们发挥自己价值的平台，同时去寻找那些弥补自己不足的员工；而不是事必躬亲，甚至在一些专业问题上不懂装懂，这样一方面自己筋疲力尽，忙于应付，自然没有发展的余力；另一方面，员工也被矮化成“手脚”，企业就陷入了发展瓶颈。有些老板说，不成呀，我不放心呀，如果公司依赖于一个孙悟空，万一他使坏，我怎么办呀？呵呵，紧箍咒呢？要建立制度约束——千万别忘了这个。
3. “仁德”
　　第三个东西，唐僧有，而孙悟空没有的是“仁德”。唐僧的仁德之心对妖怪都会怜悯性命，自然不会恶意算计自己的下属，克扣他们的工资，欺骗他们加班，对他们进行洗脑教育，利用他们承担法律责任，规避自身风险等等，唐僧虽然利用三个徒弟保护自己，但是又绝对没有恶意剥削他们的意思，而是带领他们一同努力，共同成长，一起成功。最后，唐僧的三个徒弟也都有了自己的成就，唐僧没有像赵匡胤一样，“杯酒释兵权”，或者“飞鸟死，走狗烹”。对比孙悟空，他的这种意识就差远了，他后来成了斗战胜佛，而他花果山的猴子们呢？还是一群猴子罢了。
　　日本有一家企业，把员工的父亲们都请到公司里来和管理者座谈，企业老板对所有管理者说，当你们不知道该怎么对待自己的下属的时候，就回想一下今天，这些员工的父亲把孩子托付给你们，是希望你们可以教他们成长，带领他们成功。你们要想一想自己是否对得起这样的托付。
　　中国的很多老板可能是受到了《资本论》的影响，认为做老板的只有剥削工人，才能够赚到钱，而且理所应当的认为资本的原始积累必须是肮脏的。其实，一个真正的领导是带领员工创造新的价值，带领他们一同成功的。国内有一个企业家曾自豪的说，我不想说我赚了多少钱，我只想告诉各位，我们创造了几十个百万富翁和千万富翁。
　　4. “人际关系”
　　第四个东西，唐僧有，而孙悟空没有的是——“人际关系”。唐僧的前生就是释迦牟尼佛的弟子了，而孙悟空天生地造的一个没有任何关系网络的石猴子，虽然也拜了一个师父，但是和师兄弟关系都不好，还被师父赶走了；和牛魔王拜把子，后来又闹翻了；和东海龙王是邻居，还抢了人家的东西；和二郎神等一些天官天将是同事，可是不给人家面子，后来还大闹天宫踢了很多人的屁股。总之，孙悟空的人际关系不大好。
　　而唐僧就不同了。他见到神仙就磕头，没有任何仇家。他不仅是如来佛的弟子，还是唐王李世民的拜把兄弟。人神两届的高层关系他都有了。人际关系不仅仅是好，而且还都是高层关系，通天的关系呀，这样的人做老板，就会顺风顺水。
　　社会是由人构成的，这个地球如果没有了人，一切财富，一切物质都没有任何意义。人是这个世界上最本质的资源，是所有财富的创造者。一个老板，要懂得对外创造人际关系资源，对内创造优质人才资源。
　　唐僧比孙悟空多了什么东西呢，那就是有崇高信念，无能但是懂得用人，有仁德之心，具有良好的人际关系，所以唐僧可以做领导，来领导孙悟空，而孙悟空虽然是我们心目中的英雄，但是他自己做不成伟大的事业，他必须要依靠一个唐僧一样的领导来带领。从这个意义上看，唐僧才是英雄，至少应该是我们企业家崇拜的英雄。
闲言碎语
---------------------------------------------------------------------------------------------------------
用人所长，则天下无不可用之人；用人所短，则天下无可用之人
这一句话也是看后收藏的，觉得非常有道理，对于一个公司老板，怎么管理和组织团队，还是在于用人，毕业5年出来，工作了几家公司，感觉小公司的老板都很会用人，利用有限的人力，却干出了很多的事情！对比大公司和小公司的区别：
1、大公司基本见不到老板的面，永远没有家的感觉，一切工作只为薪水，一旦失去高薪，员工会毫不犹豫的离去，而小公司老板经常和员工讨论、奋斗！一起工作，一起为事业而战，员工为和老板的交情而工作，薪水不会在乎，在乎的是得到老板的赏识！
2、大公司一旦管理不好，就会出现断层，基层和领导断层，毫无沟通，各自为战，把事情越做越乱！小公司管理灵活，沟通方便！
3、大公司高要求的运作，必然带来高成本、低效率的工作，小公司只要完成目标就好，低成本、高效率的去做！
人还是公司成败的主要因素，一旦员工失去了家的感觉，必然会离家出走！公司为什么留不住人，老板是否该要反思了，是否有唐僧的领导气质和特性？老板是要做唐僧还是孙悟空？
对于个人创业，我当然愿意做孙悟空，但是随着公司的发展，还是要学学唐僧，慢慢的放权，交给更多的孙悟空做事！

项目与产品区别

2010-03-10T08:30:00Z

项目与产品区别

咨询项目：咨询项目通常会包括二种，一种是只做咨询，像北大纵横他们只提供IT咨询，但不包括实施，还有一种就是打包，咨询和实施一起做了，给客户提供解决方案和完成网站的开发上线实施。Techsailor有些项目就是走咨询线路。

产品它基本上定位于满足产品目标用户的需求，并且努力去提高用户的体验和提升产品的值价。

我们来做个简单的比较吧。

比较项

定位

策划

核心(干系人)

管理

技术

商业目标

咨询项目

提供达到客户预期目标的整套解决方案，以客户的用户为中心，以客户的利益为核心

策划的基本方向是以客户的商业目标和客户的用户群体为中心

以客户的主脑，或项目负责人为需求的核心

一次性活动，有可预见的项目生命周期

针于客户现状和可预测的一段时期内变化的需求现实

完成客户的最终商业目标的一个整合，实现双赢

产品

为产品使用目标群体提供有价值的服务，致力于提升产品的价值和服务水平

基于产品的目标群体用户的需求和用户心理，用户体验为核心

以产品经理的策划为核心

不是一次性的项目，而是可持续性发展的产品

以可扩展和可持续性发展为核心的稳定产品

能让产品的价值持续的提升，创造更多的商业利润

以上的表格只是做了一个简单的比较，它们的区别在于，出发点和目标不一样，所以体现出来的实际工作中的策划和实施面都会有不同的重点。特别是在组织架构上的区别比较大些，项目基本上是以项目经理和项目干系人的沟通为主，以客户对项目的进度要求为准。产品很大的成份上是以产品经理的策划为核心，产品经理需要对产品的概念到设计，定位，运营，商业运作等有很清晰的规划，产品经理在整个产品应该有不可替代的“权威”，这样才能保持产品方向的一致性。产品的进度基本上是以产品的商业运作要求为准来调整上线的策略。

从管理职责上重点描述下它俩的区别，这样会更加清楚些。

项目经理的职责是在一定的目标、范围、时间期限、预算以及其他制约条件下，试图一次性完成一个成功的项目。一个项目经理需要分配资源，管理问题与风险，并且主要协调所有的各种必要因素以完成项目。当把他们跟产品联系起来时，项目也可能被要求承担起创建一个产品，为产品提供新的特征，或者是为产品创建新的版本或扩展的任务。当项目完成时，项目经理通常会被转移到一个新的项目，甚至有可能是服务于一个完全不同的产品。

产品经理的职责是从头到尾的服务一个产品，并使得产品持续成功。一旦创建产品的项目完成，而且项目经理转移到下一个工作，产品经理依然会留下来管理产品，直至产品的整个生命周期。其他项目被联系到产品可能是由于产品经理的发起，产品经理会始终在产品生命周期，定义项目的目标，并带领团队完成拟定的商业目标。

好的产品经理和好的项目经理能在冲突中找到平衡。好的项目经理明白，一个项目真正的成功并不是看它是否在规定的时间和预算内完成，而是它是否达到了拟定的目标和任务。好的产品经理则明白，如果项目被不断延期并且从未投入市场，又或者因为大大超过预算而被结束，那么所有的产品功能特征都会变得毫无意义。

产品有3个要素：一是用户，产品首先是针对特定的用户群体而开发的，以满足他们的需求为目的。二是情境，产品需要在一定的环境、条件下才能正常使用，也就是产品工作有其限制性。三是功能，产品的意义在于它能满足用户需求，能带来功用价值。

做产品的时候，需要坚持一条基本原则：用户是傻子，要从最简单的方面入手，充分考虑用户体验；此外，要意识到产品是有生命的，通过它就能让用户自动明白：这是什么产品，如何使用等，而不需要专门的人员培训。

做产品的目的是为了满足需求，而产品需求细分为3个档次，逐级提升。
最底层是以用户需求为中心，做到理解并适应用户需求；中间层是媒体需求的满足，开始引导并教育用户行为；最高级别的需求是由产品市场来决定，在不知不觉中达到控制和改变用户行为的目的。