自己下载看看啊
-----------------不要嘲笑,虽然很简单!!
http://download.csdn.net/detail/li875590079/4868072

解决方案 »

  1.   

    http://download.csdn.net/detail/li875590079/4868072
      

  2.   


    设计模式是在有问题的时候去应用到项目和解决方案中的。
    而不是在没有做任何东西是前,说我们要用XXX模式,因为这个模式用的人多,或者这个模式牛逼。
    如果没有遇到问题而选择任何一种复杂化的模式都是一种冲动。
    模式一旦产生就不会按照你想象的得以控制。不要为了模式而模式。
      

  3.   


    以下摘自于《Net企业级应用架构设计》:        从高处着眼,业界普遍认同的两种软件模式:设计模式和架构模式。在设计、编码时,我们会使用设计模式。而在概括的规划系统的整体设计时,我们会使用架构模式。还有一个值得介绍的模式是重构模式,常见的重构模式包括“抽取接口”和“封装字段”等。  他们每个模式都描述了一个问题,这个问题在我们的环境中一遍一遍的出现。且模式还给出了这个问题的核心解决方案,这个方案一次次的重用,而无需每次重头开始。一种设计模式就是一个一直且被广泛关注的核心解决方案,适用于解决一类实现过程中可能出现的专门的问题。 但是设计模式不是万能的,不能教条的使用。设计模式也不是超人,不能拯救一个陷入泥潭的项目。设计模式也许会伴你左右,但并不会给你带来额外的能力。设计模式只不过是种有用的东西,仅此而已。使用设计模式最常见的错误是逐一查看每条模式,然后生搬硬套的应用到某个问题上。相反,模式应该反过来使用,针对现有问题,尝试选择一种来解决。使用设计模式并不能在本质上让你的解决方案更有价值,真正的价值在于,在交付的时候你的解决方案是否能正常工作并满足需求。 在得到完整解决方案的过程中,对设计原则的系统化应用会让你或早或晚的来到某个已知的设计模式身边。之所以如此确定,是因为模式就是其他人已经遇到过并加以分类的问题的解决方案。模式并不能为解决方案增加价值,价值在于为架构师或者开发者提供解决方案。