WCF提供了一种特殊的终结点——元数据交换终结点（MEX终结点），通过它，服务就能够发布元数据。此外，它专门提供了一个元数据交换的服务契约接口IMetadataExchange：
public interface IMetadataExchange
{
[OperationContract]
Message Get(Message request);
}
既然要配置终结点，就必须有对应的绑定来支持。MEX终结点可以支持多种不同的传输协议，包括HTTP(S)，TCP和Named Pipe，支持MEX传输的绑定的名称分别为mexHttpBinding、mexHttpsBinding、mexTcpBinding、 mexNamedPipeBinding。
- 添加新评论
- 阅读次数：
最后期限（Deadline）是软件从业人员必须面临的最大困难与挑战，准确地说，它是所有程序员包括项目管理者的可怕梦魇。当堂吉珂德看到郊野之 上的数十架风车，风车的翅翼如巨人的胳膊，正耀武扬威地奚落着这位中世纪后期没落的骑士时，堂吉珂德如勇敢的斗士一般，跃马而上，用长枪狠狠地刺向风车， 换来的却是长枪折断，人仰马翻，最后大败而归。没错，最后期限之于程序员，正如风车之于堂吉珂德，确实是太强大以至于无法战胜。
那么，我们真的要知其不可为而为之吗？就像孟子老夫子说的那般，虽千万人吾往矣！虽然充满了风萧萧兮易水寒的悲壮，但铩羽而归的感觉，无疑会一次次挫败程序员的信心。更重要的是，IPO变成了负值，投资方是否还能够将项目交付与你呢？
风车看起来是不可战胜的，但如果善于分析风车的关键，找到其“罩门”，也未始没有击破的可能。例如，我们可以找到风车的枢纽部分，击破一点即可使其全线瓦解。有时候，最后期限真的是貌似强大，但若能仔细分析，认真对待，也未尝不可突破壁垒，找到制胜之道。
我曾经参与过多个项目的开发和管理工作，坦白说，最后期限总是如内心的毒蛇一般盘绕，始终是挥之不去的阴影。在客户的声声催促中，就像是听到了定时炸弹最后 计时的“嘀嘀”声。明知炸弹就要爆炸，自己却无能为力，这样的感觉令人沮丧。我的一个长处是善于从失败中挖掘教训，所谓“亡羊补牢犹未晚”，即使这个项目失败了，至少在下一次项目中还存在成功的可能。总结下来，大约有如下几点可以用来对付“最后期限”。
- 添加新评论
- 阅读次数：
印第安人在赶了3天路后，会停下来小憩一天，因为他要等着自己的灵魂跟上来。敏捷开发在经历了一次迭代或者冲刺（Sprint）后，也需要休整，以 等待团队的灵魂跟上来，这一过程被称之为“敏捷回顾（Agile Retrospectives）”。敏捷回顾与项目总结会议不同，它并非项目结束之后的盖棺论定，而是在项目过程中，通过回顾会议及时总结上一次迭代中的 得与失，以期达到改进项目开发、团队合作等敏捷活动的目的。
如果将项目开发比作是一次征途，那么在项目中期的短期休整是很有必要的。然而 这种休整并非是将团队成员集体拉出去＊＊一次，或者到K厅去鬼哭狼嚎一番，以泄心中的郁闷，如此种种只能说是身体心灵的休息与放松。就像是运动员在比赛期 间，队医的按摩、擦汗的毛巾、解渴的饮料。这些重要吗？当然重要，放松疲惫的身体与心灵，方能更好地走向更远的目标。但更重要的是灵魂的“反刍”，就像教 练员针对运动员在上一局比赛的盘点与指导，指出选手以及对手的优与劣，从而制定出后面比赛的对策，方能把握取胜之钥。
敏捷回顾不是一场没有主题的讨论会，大家坐下来，七嘴八舌漫无目的的一阵“乱弹”，这样的形式对于项目进展没有任何帮助。Scrum对于回顾有一个主要指导原则，这也是敏捷回顾的“最高指导原则”：
无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴。
——敏捷回顾之“最高指导原则”
听 起来，有些像一团和气的“和稀泥”做法，这样的原则会否让回顾会议的参与者一个个都变成好好先生呢？难道我们一定要善意地评价团队中的害群之马，对他们的 过错视而不见，使其“逍遥法外”，并天真地以为我们的好心能够感化他们？难道我们要在项目开发中建立一个乌托邦式的大同世界，同薪同酬，为了团队利益而抹 煞团队成员之间的个体差异。
- 添加新评论
- 阅读次数：
备注：本文的源代码例子，使用的数据库为SQL Server 2005下的Northwind示范数据库，同时为相关表建立了TimeStamp列。
源代码下载：LinqSample_Src.zip 368KB
LINQ 是Visual Studio 2008中提供的一系列新特性，用以扩展C#或者Visual Basic语言，提供了强有力的查询能力。作为LINQ的组成部分，LINQ to SQL提供了将关系数据作为对象处理的运行时架构。从某种程度上说，它相当于是微软提供的类似于NHibernate和Castle之类的ORM工具或框 架。当我们需要对数据库进行访问时，LINQ to SQL常常会成为我们的首选。
在LINQ to SQL中，关系数据库数据模型中的所有变量都是强类型的，它提供了编译时验证以及智能感知等优点。我们可以使用查询表达式（包括查询语法和方法语法）从数据库中获取数据。
然而，强类型并不利于对数据操作进行抽象，因此，开发人员就不得不为每个实体对象定义特定的类，从而导致大量的重复代码。如果我们可以实现一个共同的基 类，封装公共的数据操作，例如Select、Where、Add、Update和Delete，这对于开发N层应用程序而言，是非常有用的。
English Version：http://geekyrule.blogspot.com/2008/07/common-base-class-for-linq-to-sql.html
http://www.codeproject.com/KB/linq/linq_base_class.aspx
- 添加新评论
- 阅读次数：
设计没有标准，只有目标。如果硬要制定一个标准，那么标准就是快捷、适用与优雅。如何从没有标准的设计中体验设计的乐趣，寻求问题的解决之道，成了 我们软件设计者生命不可承受之重。与众多创造了灿烂文化的艺术家一样，作为软件产品的设计者，设计常常成了一种苦闷的象征。就如困守在地球之上的古代人类 一般，因为渴望飞翔的自由，于是搔首问天，俯仰天地，体察宇宙与璀璨的星辰，从而发现了天体的运行轨迹与宇宙的奥秘。软件设计师在经历了众多挫折与失败后，似乎也得到了一种指引，逐渐地开始了探索设计之道的奥秘，企图叩开那道紧紧关闭的镂有神秘咒语的设计之门。
终于，设计大师们获准进入了那穹顶高悬的殿堂，此时才发现我们又进入了一座迷宫。正是这样，当今的软件设计，不患无标准，而患标准何其之多。在众多设计标准之前，我们都希望找到最好的设计方案，然而什么是最好，每个人都有自己心中的“哈姆雷特”。王子复仇记可以在不同的舞台上被演绎为各种不同的版本，不过对于软件设计而言，我想我 可以说：满足客户需求的设计就是最好的标准！然而，前提是怎样通过设计来满足客户需求？
- 添加新评论
- 阅读次数：
在2月11日，J.D. Meier在其博客上宣布Patterns & Practices WCF Security Guide发布。这对于众多WCF开发者而言是一条好消息。面对WCF开发中的安全问题，终于有了一篇权威的指南来规范和指导开发者的设计与实现，实属幸事。
...
- 添加新评论
- 阅读次数：
QCon是 为团队领导者、架构师、项目经理和高级软件开发人员量身打造的企业软件开发大会，其所覆盖的主题内容与InfoQ相同，关注架构与设计、真实案例分析等 等。从2007年3月到现 在，QCon已经在英国伦敦、美国旧金山等举办了4次会议，得到业界的广泛好评。2009年，这一高品质的技术大会将来到亚洲，在中国北京和日本东京举 行。
QCon北京站的主题和演讲人已经基本确定，讲师也已经确认了近85%，包括：
- Rod Johnson——Spring创始人，Java和Java EE开发领域世界级权威
- Martin Fowler——《分析模式》和《重构》等书的作者，敏捷宣言缔造者，ThoughtWorks首席科学家
- Randy Shoup——eBay高级架构师
- Jeff Bar——Amazon公司云计算战略师
- Dylan Shiemann——Dojo Tookit创始人
- Henrik Kniberg——《硝烟中的Scrum和XP》作者
- Floyd Marinescu——《EJB模式设计》作者、InfoQ和TheServerSide创始人
- 毛新生——IBM中国开发中心Web 2.0首席架构师
- 李伟——西门子中国研究院软件与工程中心首席系统架构咨询顾问
- 周爱民——《大道至简》和JS语言精粹等图书作者，盛大前高级架构师
- 高焕堂——台湾软件架构设计大师，“台湾OO技术教父级代表人物”
- 洪强宁——豆瓣网技术总监
- 程立——支付宝首席架构师
- 周代兵——华为软件公司软件工程部总监
- 于晶纯——Freewheel创始人/CTO，DoubleClick前工程部副总裁
- 邵荣——群硕软件的资深技术总监
- 林昊——OSGi China User Group负责人，淘宝网平台架构师
- 麦天志——Odd-e公司团队教练，InfoQ中文站敏捷社区编辑
- 添加新评论
- 阅读次数：
缘起
用过去几年互联网上最酷，而在当下已经被用滥的名词来说，我在2004年成为了一名博客，用日志的方式记录自己成长的经历。坦白说，技术的成长远远比身体 的发育更加地艰辛与缓慢，尤其是当今信息爆炸的年代，我们担忧的不是吃不饱，而是应该怎么吃，吃什么？营养不良固然令人堪忧，营养过剩却也不是健康之道。 如果我们对软件技术做一次全方位的扫描，收获的无疑是面对岔路口的彷徨与迷茫，就像博尔赫斯笔下的曲径分岔的花园。
这是一种梦魇，就像在我的儿童时代，每次发高烧都会做的同一个恶梦一样，跑不掉，挣不脱，惊醒之后却又说不清的感觉。没人愿意走迷宫，除了那些以解谜题为乐趣的天才们。所以，我们在软件设计的迷宫门前停住了脚步；然后，四处顾盼寻找通过迷宫的地图。
不知道世界上是否真的存在穿过软件设计迷宫的地图，但至少有人曾经通过，并且留下了淡淡的足迹。这些足迹或者交互重叠，或者纷繁杂乱，分不清哪里才是走过的正确的路。于是，寻找、识别与尝试就成为我们面对技术更新的时候要经历的三部曲。
经典的技术，特别是经典的设计思想，完全可以免去这几个步骤。例如设计模式，在面向对象世界里，它已经成为了经典的存在，我们不必浪费时间去质疑它的重要 性。省去了寻找、识别与尝试的过程，我们可以直接将它设定为亟待攻克的堡垒。正是基于这样的目标，我开始尝试与广大博友分享我的战斗攻略与心得。
博客的风格是“童言无忌”，所以我能够自由写意地耕耘博客园的一块田地。俗语云：种瓜得瓜，种豆得豆。我种下了技术的种子，吸收着评论的养料，最后收获的 却是现在这本呈现在读者面前的《软件设计精要与模式》，连我自己也要感到莫名惊诧了。书的出版缘起偶然。在我做完了一个长达一年多的项目之后，又参加了另 外一个大型项目最后阶段的开发与测试，最后拒绝了一个周期可能长达几年的项目安排，结束了在北京的漂泊回到故乡。我开始了悠闲自得的放假生涯。一次偶然与 博客园站长杜勇先生的闲谈，结束了我的休假状态，开始了数月的写书生涯。对于杜勇先生，我想把感谢的话放在本文的末尾，此时只想表达我的“愤慨”，是你， 谋杀了我的闲适生活☺。
好在我这本书成不了指引人们走出迷宫的地图，所以我可以“没有责任心”地回过头来欣赏自己在迷宫墙上的涂鸦，即使是一个人的艺术，对于自己而言，也是一种美。萨特说：“存在即合理”，我相信本书能够体现这种逻辑的合理性。
- 添加新评论
- 阅读次数：
“ 给我一个支点，我就能撬起地球”。关键不在于力量有多大，而在于如何合理地利用力量。软件设计同样如此。思想的确立，技巧的把握，将在很大程度上决定软 件架构的合理性。基于这样的目的，本书围绕着软件设计的核心内容，结合大量的实例与代码，充分地展示了软件设计之美，以及设计“力量”的巧妙运用。内容涵 盖了设计模式、重构、测试驱动开发、极限编程、软件体系架构设计等重要的设计方法与技巧。这些内容是软件设计中最重要的“流行元素”，是程序员向设计师“ 涅磐”的基石，是从小工到专家的修炼法门。
本书没有高文大册般的晦涩难懂，却又多了几分一般技术书所没有的温情与雅韵。作者力求从枯燥的技术描述中，带出几分文学作品的情趣出来。谁又规定技术书一定要板着脸孔教训人呢？
- 添加新评论
- 阅读次数：
我在阅读Ken Schwaber所著的《Agile Project Management with Scrum》一书，就对ScrumMaster的其中一个职责抱有怀疑的态度。Scrum要求ScrumMaster保证开发人员在一个Sprint（冲 刺）过程中，不受到其他无关人员尤其是上司们的干扰。真的能做到这一点吗？即使ScrumMaster通过有效地与Product Owner沟通，确定了Product Backlog；然后我们开启了一个Sprint，并确认了Sprint Backlog；然而，根据客户的需求，一旦需求发生变更，我们还能保证Sprint不受到这一变更的影响吗？
- 添加新评论
- 阅读次数：
张逸(Bruce Zhang)
