之所以仿照CE，一是因为他的界面最酷，二是因为它的源代码用了混淆，做类似的实现比较有意思。

不过，现在想来选择CE做蓝本是一个错误。因为除了界面比较酷之外，他的服务器端代码很烂，一方面为了达到更好的混淆，用了大量的内部类，另一方面用了很多奇怪的方式实现控件。把许多简单问题，弄的很复杂。

RadEditor是这两天我刚看到的另一个编辑器，它的界面很酷，服务器端代码也很好。他的服务器端实现和我的想法很相似，比较符合正常人的思路。可以说是，把复杂问题简单化了。只是看到这个实现时，第一阶段已经完成。

今天看到一个报道说“从公布的录像来看，日本隐形战斗机实际上是F-22的翻版，整个外形几乎一模一样，配备两台具有矢量推力的发动机，虽然看不到武器，但所有武器似乎也是内置的。如此看来，日本隐形战斗机为了“少走弯路”，几乎“全盘借鉴”了F-22的设计思路。”

同样，为了完成WordEditor，从头空想，一点点的实现，远不如以现在某个比较成熟的项目为蓝本，先仿照他的实现，然后再按照自己的思路重构。

这样可以：

1、  弥补自己的不足，如此项目中的Javascript。

2、  一开始项目就达到了比较高的水平。

3、  吸取他的优点，并避免它的缺陷。

第二步，重构服务器端代码（估计两到三周时间）。

由于CE的服务器端实现，很不符合正常的思路，只是说和我的想法差别很大。这一阶段会按照我的思路改写上一阶段的部分实现，如改写资源管理、Gzip。

重构完成后会发布源代码。

第三步，把控件移到Ajax平台。

这一步是最关键的一个步骤，这一步完成后，这个控件才算真正的开始。

首先，把服务器端代码移到Ajax，可以利用asp.net ajax的基类，会省去服务器属性和脚本的映射代码。依靠Ajax平台，也使这个控件的扩展性和稳定性增强。

其次是，客户端脚本的重写。由于我js不好，这一步是比较头疼的问题。不过，有许多现成的脚步参考，应该也不会太难。

有想加入的可以和我联系，一起学习Ajax，我觉得以开发控件的方式学习，也是不错的途径，边学边写。要求熟悉Ajax。msn:hao_ding@eyou.com 

1、  用WordEditor.dll替换掉CuteEditor.dll。

2、  把Dialog文件夹替换为附件中新的Dialog

使用方法，参考cuteeditor的文档
代码下载：
http://www.cnblogs.com/files/bluewater/cuteeditor.rar
效果图：

关于Cuteeditor：

他的服务器端实现很诡异就不多说了，他的客户端也是如此，以简单的toolbarbutton为例子：

<img command="Save" postback="True" alt="保存" themeindex="0" />

下面是Freetextbox

<img src=”bold.gif" border="0" title="Bold" unselectable="on" width="21" height="20" tabindex="-1" style="margin:0px;padding:0px;" align="center" />

下面是RadEditor

<img src="/DEMOS/ASPNET/RadControls/Editor/Skins/Default/buttons/Bold.gif" alt="Bold" title="Bold" />

当然，CuteEditor优点也不少，如事件处理方式。总之CE的实现方式和独特。
这个项目总览
http://www.cnblogs.com/bluewater/archive/2007/09/06/884990.html

几个Editor比较
http://www.cnblogs.com/bluewater/archive/2007/09/06/885001.html
cuteeditor6破解
http://www.cnblogs.com/bluewater/archive/2007/09/06/885006.html

      编辑器项目

       由于我对Javascript了解很少，编辑器只能想想，并没有能力去实现。后来又有机会学习了Ajax，系统的学习了一次Javascript。这时我觉得可以有实力去做这个编辑器了。

       不过，我对自己的Js缺乏信心，想到一个捷径，利用一个现有Editor的脚本文件。我只重写服务器端的代码，这样一来可以省去Js的麻烦，二来也可以在第一个版本就尽可能的做到比较实用的效果。这个版本出来后，可以再考虑，自己写脚本，我希望这个脚本是基于Ajax.net的脚本库。

      Word解析项目

       最初解析word是因为公司一个项目的需要，这个项目需要把word转换成html，编辑html后能把修改再写入到word。以及把一些自定以表记转换为html标记。

       当时听说了wordprocessingMl，就以他为基础解析，。为了简便，当时只解析了部分word标记。

       由于当时的解析是基于word2003，第一次做，对那次解析也不满意。我有时间的时候，开始基于word2007解析word。这次做的很彻底，完成了word中90%以上标记的解析。

       有一天，我忽然想到这些解析一开始，就走错了方向。主要是被WarstarDev.Office2k7项目误导了。我是在用链表描述树结构，这才造成对xsd的一些元素如组，sequence,choice等很难用List描述出来。在word2007的解析中，我主要的时间都花在了如何简单准确的描述树结构，但不论怎么努力，结果都是差强人意。正确的做法应该是，解析的核心，仍然用树描述word，在暴露给客户的接口上，才需要基于这些树，做些façade。Asposeword好像就如此做的，我当时看他源码的时候，还对他用树描述word有些嘲讽，其实这才是正确的做法。

       这些解析的优点是，可以脱离word来操作word文件。至少从效率上，比调用vba或者vstc（？）快很多，因为它没有必要调用word内核。

目前的一些进展：

Word解析方面：

这是转换的一些截图，版本是最初项目用到的2003版本。

包含标记的word

对应的html，把word重的textbox标记转换成了文本框，保留标记替换成了文本。（注，由于忘记考xsd，这些标记显示不出来）

包含表格的word

对应的html

Editor的进展：

这个刚开始做，不过到今天总算完成了服务器端的大部分工作，如果有时间，再过两周就会有一个实用的版本出来。

截图。

后续的想法：

Word的解析部分，整个从新开始。目前先不做这部分，不过因为又以前的基础，这部分比较有把握完成。

Editor部分，控件开发和Js以前都没有做过，一直对他没有底。不过，由于现在服务器端以经完成了一半多，也算稍微有把握了。

在这个项目的目标是，Editor方面，首先赶上Cuteeditor，word方面，赶上asposeword。然后再在Editor上加操作word的功能。

整体的结构图，比较粗略

这个图不详细，依赖都应该是关联，由于这个软件表示有方向的关联比较麻烦，我一般都用依赖了。

写这篇文章有两目的：

一是，不想一个人做了，凭我一个人的力量，恐怕到明年这个时候才能完成。

二是，提醒自己，不要放弃，把这个项目完成。

目前，想找个熟悉JS的，我们可以一起完成Editor的脚本部分。新的脚本会基于Ms的Ajax脚本库。我负责把服务器端迁移为Ajax控件（是否这点有必要？）。

如果想一起做，可以和我联系：msn：hao_ding@eyou.com,联系之前首先考虑下自己Js的水平，因为我js不行，想找个高手。

附录一：
Hibernate成功的原因　　
　　1、飞快的版本发布
　　
　　保持活跃的开发速度，经常进行版本发布，甚至几天 之内就从前一个版本开发到下一个版本。这样是保证软件远离Bug的最好的办法，也可以让用户感到很放心，确信Hibernate的开发十分活跃，另外这样做也有一大好处，就是可以发现哪些功能是用户真正需要的。
　　
　　2、回归测试
　　
　　我想现在整个Java社区一定都很重视自动回归测试。如果软件的功能和设计有比较大的修改，那么一个综合性的test suite对于软件可维护性和稳定性来说实在是太重要了。我们应该有这样的意识：如果对软件的一个新功能没有进行回归测试，我们根本就不该去做它。
　　
　　3、把一个功能做到最好
　　
　　要么不做，要做，就一定做到最好。那些我们做不到最好的功能，我们根本不去做，扔给其他软件去做吧。
　　
　　4、避免过度设计
　　
　 　浪费大量的时间和精力进行软件功能的抽象和扩充软件的灵活性，还不如多花点时间来解决你的用户面临的实际问题呢！简单一点，软件最重要是运行起来，不要 尝试去解决你的用户根本不关心的问题。就算你的软件设计的不够优雅也没有关系，反正还是initial阶段。以后还可以再refactor，你应该关注的 问题是及时的把有用的功能给做出来。

　　
　　5、集权
　　
　　在你需要由民主投票来下决定之前，至少你已 经把软件轮廓做好了。软件开发需要由一两个开明的人来领导，这样可以保证软件开发的连贯性而不至于产生太大的分歧，可以保证开发团队集中火力把要实现的功 能做到最好。我觉得，OSS软件最大的风险就是意见不统一，摊子铺的太大，结果最后搞的什么都没有做好。
　　
　　（译者按：非常赞同，凡是成功的OSS软件，都是在某个人已经把软件做好了之后，发布出来，然后由大家往里面添加功能的，并且在这个人的领导下不断进步。缺乏此人的OSS软件都不算很成功，比如Mozilla）
　　
　　6、文档
　　
　　没有什么比文档更重要的了。如果你的用户不知道你的软件有这么一个功能，就等于没有这个功能，干脆把它去掉得了，省得给源代码增加复杂度。
　　
　　7、避免标准化
　　
　　好的标准可以带来软件的互用性和可移植性，坏的标准能够窒息软件创新。最好的软件是在不断的尝试，不断的出错，不断的经验积累的过程中产生的。事实上的标准往往更加贴近用户需求。
　　
　　8、10分钟之内把Hibernate跑起来

　　
　　潜在的Hibernate的用户在他们下载了Hibernate，第一次使用的时候根本就不可能花半个小时那么多时间来安装、配置和 troubleshooting，他们早就丧失了对Hibernate的兴趣了。
　　
　　我们的口号就是新用户（假设有足够的JDBC知识）5分钟之内把 Hibernate的Demo跑起来，而他们能够在1个小时之内写出“Hello World”式的最简单的Hibernate程序并且正常运行。
　　
　　9、开发人员的责任感
　　
　　用户总是不可避免的碰到问题，开发团队有责任有义务提供帮助。用户让我们知道了文档的漏洞，用户让我们知道了测试用例的小bug。此外，没有用户来用我们的Hibernate，我们还开发它做什么，不是浪费时间吗！
　　
　 　有个关于bug的笑话：用户根本不介意发现新功能的bug（译者按：Windows的用户好像都是如此），只要你能迅速的改掉bug。“责任感”意味着 bug修复应该在1周之内。从收到bug报告到bug修复代码提交到CVS上要做到平均在24小时左右，这才是一个理想的目标。
　　
　　10、易用的、可更新的wiki网页
附录二：
目前两个商业项目：
cuteeditor，http://cutesoft.net/
他的价格：从129到7999
http://cutesoft.net/ASP.NET+WYSIWYG+Editor/Purchase+CuteEditor+for+.NET/default.aspx
aspose word，http://www.aspose.com/Products/Aspose.Word/
价格：从899到10788
http://www.aspose.com/Purchase/Aspose.Words/Default.aspx

首先是FreeTextbox

此控件是生成的控件（相对于复合控件），不论是toolbar还是toolbaritem，都不是以子控件的形式存在，因此有更好的性能。这种方式的缺点是，不能很好的利用现有的Asp控件，降低了用户自定义控件的方便性。如，我想在toolbari上加上combox，必须自己实现。

视图状态，视图状态的管理是令人头疼的问题，弄不好就会加大视图状态的大小。从Freetextbox对视图状态的实现来看，它的实现中规中矩，完全符合ms推荐的实现方式。但是，是否每个toolbaritem都有必要实行视图状态？其实从Freetextbox的实现分析，大部分的实现是不必要的，因为他们都不会改变。如果把这些实现剔除，Freetextbox的代码会简单很多。

子控件的实现方式，此控件不存在子控件，toolbaritem被定义为实现了IstateMananger的类，每个Item都是一个类，如Bold，Italic等。

总之，这个控件的服务器段代码，十分符合MS推荐的控件实现方式，它的内部实现，类似于ASP的服务器控件实现。也符合常人的思路，代码比较容易理解。结构也不错可以给80分。

其次，Radtoolbar

此控件用的是复合控件。每个toolbaritem都被实现为子控件，并且暴露给客户。从用法来看比较像asp的一些复合控件，即子控件要在aspx中声明。但这种方式对客户来说，用起来很不方便，因为要写许多声明代码。

视图状态，此控件对视图状态的管理，可以说坏到了极点。它竟然通过把控件的属性序列化为xml，然后把xml作为视图状态。这就造成，任何一个细微的改变，都会把视图状态项记为dirty，造成整个xml序列被序列化的客户端。再者xml本身就包含许多不必要的文本，如<sdds>ss</sdds>。可以看到元素名称是很浪费空间的。这就造成此控件的视图状态，会比标准的asp实现大十倍左右。

子控件的实现方式，子控件是通过序列化的方式从配置文件读取。子控件没有细分，如没有类似于Bold，Italic的项。只被粗略分成了Toolbarbutton，toolbarseprator等。

总之，这个控件实现没有细看，因为不论从哪方面来说，它都算不上优秀。50分。

AboutEditor

这个控件的实现类似于Freetextbox，也不是复合控件。

视图状态，他没有为toolbarItem实现视图状态，因为这几乎没必要。

子控件，他同样不存在子控件，与freetextbox的不同在于，他没有细化每个toolbaritem。

总之，此控件和freetextbox很相似，我没有细看。

最后是Cuteeditor

看了他的demo，很震撼，应该是所有editor中效果最好的。

Cuteeditor用复合控件实现，缺点是增加了控件树的开销，效率没有生成控件高。优点就是，客户实现自定义功能较方便。

由于用子控件，大部分视图状态都可以交给webcontrol管理。

他对子控件的实现我认为不算太好，简单的控件都从一个基类派生，这点如果还算不上缺点，那么他对Forecolor等的实现方式，确实不算好。

总之cuteeditor是功能里面最强大的。但是他的实现，很难让人理解。不像Freetextbox,有中规中矩的实现。60分。

看了几个实现，可以说实现方式五花八门，除去视图状态不谈，只要把htmlrender到客户端，控件就算完成了。这就造成实现控件的方式很多。应该怎么写，确实值得思考。

Freetexbox，占去了大概一周的时间，这段时间我仔细看了他最新版本，以及更早版本的代码，它的实现和符合正常人的思路，很容易理解。对他的实现了解太多，以至于不想参考他的实现了。主要是怕写完代码和他特别像。从结构上来看，它的缺点我认为主要在于，把子控件的生成操作，都延迟到了父控件，造成父控件逻辑负杂。我最初的想法是，在Init的时候，构造一个xmldocument，然后每个子控件通过xml的方式，增加xmldoc的节点，最后再返回xmldoc给父控件。

Cuteeditor用了两三天的时间，他的代码很乱，几乎不符合常人的思路。尤其他为了防止破解，故意调整了几个类的顺序，如Editor，嵌套了四五层的内部类，让人看起来很头痛。从他的html看，也不像其他控件一样，能得到许多有用信息。

由于他的效果最好，并且我看了好久都没有头绪，觉定从他下手，写一个类似的editor。

其他的几个控件，和这两个相比都差很远，忽略。

经过近一个月的努力，控件开发终于过半，对cuteeditor的研究也更深入了，觉得他的许多实现确实很诡异，也让人眼前一亮。增加到80分。

Cuteeditor特点

首先，它对资源文件的处理方式来看，他没有采用.net的资源文件，也不是通过自己定义资源管理类来在用到资源时本地化。而是通过重写Textwriter的innerwriter和response的filter实现。细节上，他用到了Idispose接口和using语句，这样在缓冲去满，或者dispose时，自动实现资源的本地化。简直是绝了，我一直没有想过能这样用dispose和这样实现资源。

其次，对事件的处理，这也是cuteeditor做的很好的地方，它把所有的postbackdate和postbackevent，封装到了两个隐藏域中，这两个隐藏域是两个webcontrol，他的值为post的数据和事件。这就使新增事件及其简便。只要加上postback=ture，就可以处理回发。

其次，对脚本的管理，他的脚本都是动态加载的，因此不能调试。又是一个防止破解的招数。

通过httphandler，他托管了*.js的加载。

再次，配置文件的管理，他在运行时，会把几个配置文件加载到一个xmldoc中，实现统一管理。Js也实现了类似功能。

还有，Gizip，以及缓存的管理方式，都和一般人的不同，感兴趣的自己去看源码。

类似的诡异实现还有很多。

我写的editor，主要在下面几点做了改进：

首先是，子控件的管理上，他的管理方式不算好。我把类似ForeColor的控件都抽出了基类。

其次，我认为应该让客户更简单的自定义控件。因此在这点上也有改进。

再次，net2.0已有的功能不再自己实现，如Gizp，在2.o已经有了Gizpstream。

我希望用Ma.js重写他的客户端脚本，因此在服务器端尽量做些支持。

看了回复才知道还有个RadEditor，看了他的代码和效果。发现它才是最好的。90分吧
其中，界面满分20。cuteeditor和Radeditor都是20分。freetextbox10分
服务器端代码部分，ce60，freetextbox70，radeditore70。满分80
 

终于决定破解，以前从没有想过要破解，总感觉这样做很不道德，但是实在是被这个bug折磨烦了，只能破解后看看他的执行流程。没想到第一次破解竟然用了近一天时间，不过最终还是搞定了。

服务端代码破解：

首先反编译为IL，找到动态生成js的代码，让他加载指定的文档。修改完后，编译为dll。原以为搞定了，可是，编译时出现了，签名错误。

去掉强命名，不成功，让clr跳过强命明检测，仍然不成功。

因为私钥是不可能获得的，这就没有办法生成新的hash值，只能走最后一步了，重新生成私钥和公钥。重新对程序集进行签名。

这次终于没有了编译错误，可是跑出了null引用异常。一般人到这一步基本就很难再进行下去了，因为从异常看不到什么有用信息。因为我对cuteeditor的代码比较熟悉，才能继续进行下去。

下面是另一个cuteeditor诡异之处，他在初始化Editor类时，要用到token。以此来防止代码被修改。但是要找到这些信息比较难，一是他用了混淆，二是，这些信息被封的层次很深。

还有这个token被以类似随机数的机制编码：

  string str2 = new string(new char[] {

            (char) ((length + 0x2f) + 4), (char) ((length + 0x27) + 0x11), (char) ((length + 0x24) + 9), (char) ((length + 0x18) + 0x1d), (char) ((length + 0x35) + 3), (char) ((length + 0x20) + 13), (char) ((length + 50) + 15), (char) ((length + 8) + 0x39), (char) ((length + 0x27) + 6), (char) ((length + 10) + 0x2c), (char) ((length + 0x17) + 0x21), (char) ((length + 10) + 0x23), (char) ((length + 0x2d) + 3), (char) ((length + 8) + 0x2a), (char) ((length + 0x23) + 10), (char) ((length + 0x26) + 0x1c), (char) ((length + 3) + 0x2e), (char) ((length + 0x29) + 4), (char) ((length + 8) + 0x2a), (char) ((length + 0x25) + 13), (char) ((length + 0x23) + 10), (char) ((length + 0x25) + 14), (char) ((length + 14) + 0x33)

         });

上面的str2就是token值38-58-AA-68-02-B1-22-3A。是不是很难找到？

到此，破解基本结束，只要用新的token替换掉str2即可。

用新的程序集替换后，终于可以调试Js了。

网上还没有6.0的破解版，我估计都在token上卡住了，因为他的licence控制程序并不难找到，感兴趣的可以自己做破解，破解完后用我的私钥做强命名。

另一种破解方式：

对于一些简单的修改，如改变方法名，更改常量。有另一种简单的方式，我没有式过，不过理论上可行。

首先以二进制格式读取，dll。

其次，根据pe头，运行环境头找到strings和US流的地址。根据Token值计算初偏移量。计算方法可以看我以前写的一个文章http://www.cnblogs.com/bluewater/archive/2006/10/17/531639.html或者何宗键的blog。

最后一步是，修改strings和Us流的信息。

怎么读混淆后的代码

混淆对我们来说，是不可逆过程。破解是不可能了，但是可以找到一个突破口，一点点的读取。如.net类不能被混淆，我们可以通过这些信息去分析源代码。

不过总体来说，这些基于元数据的语言，是不可能阻止破解的。原数据表必须把信息暴露出拉，以便让clr加载。除非MS，在加载器和dll间，另加一个解释层。但是这么做效率会很低，原数据的存在也变成没有意义了。

JS破解：

Js也用到了混淆，这是没有办法破解的。不过，可以做一些简单的替换来使他易于阅读。如：

function CreateXMLHttpRequest()

{

   if( typeof (XMLHttpRequest) != OxO7c60[0x0])

   {

      return  new XMLHttpRequest();

   }

   ;

   if( typeof (ActiveXObject) != OxO7c60[0x0])

   {

      try

      {

         return  new ActiveXObject(OxO7c60[0x1]);

      }

      catch(e)

      {

         return false;

      }

      ;

   }

   ;

   return false;

}

;

function LoadXMLAsync(Ox878, Ox26a, Ox19e, Ox879)

{

   var Ox12e = CreateXMLHttpRequest();

   function Ox87a()

   {

      if(Ox12e[OxO7c60[0x2]] != 0x4)

      {

         return ;

      }

      ;

      Ox12e[OxO7c60[0x3]] = new Function() ;

      var Ox75b = Ox12e;

      Ox12e = null ;

      Ox19e(Ox75b) ;

   }

   ;

   Ox12e[OxO7c60[0x3]] = Ox87a ;

   Ox12e.open(Ox878, Ox26a, true) ;

   Ox12e.send(Ox879 || OxO7c60[0x4]) ;

}

;

格式化后为：

function CreateXMLHttpRequest()

{

   if( typeof (XMLHttpRequest) != undefined)

   {

      return  new XMLHttpRequest();

   }

   ;

   if( typeof (ActiveXObject) != undefined)

   {

      try

      {

         return  new ActiveXObject('Microsoft.XMLHTTP');

      }

      catch(e)

      {

         return false;

      }

      ;

   }

   ;

   return false;

}

;

function LoadXMLAsync(Ox878, Ox26a, Ox19e, Ox879)

{

   var Ox12e = CreateXMLHttpRequest();

   function Ox87a()

   {

      if(Ox12e['readyState'] != 0x4)

      {

         return ;

      }

      ;

      Ox12e['onreadystatechange'] = new Function() ;

      var Ox75b = Ox12e;

      Ox12e = null ;

      Ox19e(Ox75b) ;

   }

   ;

   Ox12e['onreadystatechange'] = Ox87a ;

   Ox12e.open(Ox878, Ox26a, true) ;

   Ox12e.send(Ox879 || '') ;

}

破解后的文件：
http://www.cnblogs.com/files/bluewater/cuteeditor.rar

私钥：
 http://www.cnblogs.com/files/bluewater/t.rar

称这样能减少代码，提高开发效率，但是用Nhibernte大部分人也不会手写代码，而是通过工具生成，这样这点其实优势不大。

不可否认这样做在修改时更方便，不用修改两个文件（DRY）。

但是缺点也很明显，特性不可能完全映射配置文件，否则特性会把类弄的很乱，这也使AR只能是Nhibernte的子集。另一个缺点是，特性使域对象变的不单纯，移植性差。再一个，特性效率也比不是解析xml。

其次，AR给每个域对象增加了基类，这点同样是域对象难以移植，恰巧移植性是Nhibernte的优势。

还有，AR对Session的管理，是他的一大优势。一些项目如Cuyahoga，只用到了AR的Session管理，而没有用其他的封装。但是最新的Nh（1.2）也逐渐提供了内置的Session管理，这也变的不很必要。

再一点，如果不懂Nhibernate，我相信只看AR的API也很难实现些复杂的应用。

因此对于新手来说，最好从Nhibernte开始，然后过渡到AR。

AR应该在其他方面多做些工作，而不是单纯的去封装Nh的API，如提供些好的业务层模式的封装，可以使更好的分离业务逻辑，就像现在的Customquery，实现可以把复杂业务规则封装为一个类。

还有，发挥Castle的优势，在动态的生成些可以改进NhSession缓存的IL。

主要参考了下面几篇文章

http://codebetter.com/blogs/jeremy.miller/articles/129542.aspx

http://codebetter.com/blogs/jeremy.miller/archive/2006/02/01/137457.aspx

http://haacked.com/archive/2006/08/09/ASP.NETSupervisingControllerModelViewPresenterFromSchematicToUnitTestsToCode.aspx

http://www.martinfowler.com/eaaDev/SupervisingPresenter.html

http://www.martinfowler.com/eaaDev/PassiveScreen.html

在asp.net中用MVP的原因：

        在软件设计中最重要的一条原则是“分离关注点”，每一段代码有且仅有一个职责，才那能使程序有良好的可维护性。即使在编码的起点，也应该明确一次只解决一个问题，如，我希望只关注业务逻辑而不管数据库结构、html等。

        构建可维护的用户界面代码的传统做法是MVC模式。可惜，asp.net为RAD做了优化而没有关注创建可维护性的代码，asp.net模型本身就没有对MVC提供很好的支持，许多asp.net程序把数据访问、html标记、业务逻辑混合在了一起，code－behind模型也没有很好的分离关注点，再加上code－behind很难做单元测试，这些都是要引入MVP的原因。

MVP和MVC问题：

        Code－behind的作用？

        Code—Behind不能作为MVC的控制器，他只能作为单纯的View，许多维护问题都是由把Code-Behind作为控制器引起的。在MVP中Presenter不能引用System.Web名称空间，是P依赖于V。即使其他的模式也应该尽可能的使Code－behind的只作为界面（View）的辅助，而不包含业务逻辑、控制代码。

   MVP中V和MVC中V的区别？

   V在MVP中是界面的非常简单的包装（一定要简单到不涉及逻辑问题），MVC中V是指完全被动的。

MVC的类结构

   目的是要把尽可能多的功能从asp.net运行时分离出来，也就是说把Page的职责分解到几个类中：

View：显示数据、把用户输入和触发的事件推迟到Presenter。

   通常需要一个接口（Interface），代表所有的View，后台代码把此接口当作界面，而不需要Page、system.web中的类，此接口封装了与asp runtime的交互。

界面和后台的逻辑都通过此接口传递信息。

Presenter：协调View和后台服务、业务逻辑，负责页面逻辑。P只能依赖于IView、Modle（最好用Facade模式，提供一个中间层，隔离Model）。P的功能不能太多，MVP中P负责的一般比MVC的C多，但是从功能上细分P到几个类有时是必要的，如验证、分页、排序等，使P不至于便的很大，并且有内聚性。

V的要点：

1、V必须依赖于接口Iview

2、 IView，尽量减少简单的POCO似的属性，而要把这些封装成类或者暴露DTO，甚至MOdle，如

public interface IWorkItemView

        {

               // Packs the user input into a new WorkItem class

               WorkItem WorkItem{get;}

               // Sets the values in the dropdown list for the WorkItem assigned to user

               string[] AssignmentList {set;}

               // Sets the values in the dropdown list for the WorkItem categories

               string[] CategoryList {set;}

        }

public interface IWorkItemView

        {

               string AssignedTo {get; set;}

               string Category {get; set;}

               string Description {get; set;}

               string Priority {get; set;}

               string Comments {get; set;}

                /* More properties */

        }

P的要点：

1、View可以有多个Presenter，如一个负责低层次的View和Model映射和验证。另一个Presenter负责业务逻辑和后台服务

后面的找不到了 

库的改变：

1、 增加了一个接口，

public void CommonProcessNotify(Page page, string verifyUrl, string key, Verify verify, string encode)

这个接口触发NotifyEvent事件，此事件通过NotifyEventArgs类型暴露了支付宝Notify通知的所有参数，并且不给支付宝回发“success”或者“fail”，回发由调用者实现。这个方法提供了支付宝Notify通知的所有功能。

    如果仅仅需要处理下面几个事件，可以参考：http://www.cnblogs.com/bluewater/archive/2006/10/16/530630.aspx

WaitBuyerPay

WaitSellerConfirmTrade

WaitSysConfirmPay

WaitSellerSendGoods

WwaitBuyerConfirmGoods

WaitSysPaySeller

TradeFinished

TradeClosed

这几个事件细化了支付宝的Notify通知，定义了最常用的几个事件，调用起来要方便些。

2、 记录了日志记录功能。

用Log4net记录了Request.Form集合，可以看到支付宝Notify发过来的整个参数，便于调试。日志默认是Error级别，并且只有在debug版本有日志输出，实际使用时应该用release版本的库（或者修改Log4net的日志级别），以免记录下许多无用的日志。

调用方式的改变：

用Notify接口模拟出了Return方式。支付宝的Return接口虽然方便调用，但是安全可靠性差，很难在实际中应用。通过下面的方式，可以用Notify模拟return，如果支付宝的Notify发送的及时还可以完全替代Return方式。

解决方法是：让提交给支付宝信息的页面一直等待，直到收到Notify通知。

         AutoResetEvent ansyCard=new AutoResetEvent(false);

        ansyCard.WaitOne();   //阻塞当前线程，直到Notify完成。displaycard.aspx

ansyCard.Set();//在Notify页面发解除阻塞通知,displaycard页面继续执行。Notify.aspx

思路就是上面那么简单，但实际上还有几个问题：1、支付宝服务器发Notify页面和其他的页面不在一个线程，不属于用一个Session。2、支付宝会一直发Notify，必须要保证，解锁的是设置锁的那个线程，而不能把其他的线程锁解开。

详细的实现方式可以看源代码，此方法可为解决这种类型的问题提供了一个思路。

调试：

调试支付宝必须满足两个条件：

1、 有个公网IP，如果是ADSL每次拨号也会分配一个，可以通过ipconfig命令查到此次拨号分配的IP，这样支付宝就能访问到你。

2、 必须附加到IIS，一是通过手动附加到aspnet_wp进程，二是把启动选项的服务器改称虚拟目录的地址。

满足上面两个条件就可以调试支付宝了。

源代码的使用方法：

修改web.config中的下面几项后，就可以直接运行实例程序。Temp.aspx是测试AutoResetEvent的页面。

<add key="key" value=" "/>

    <add key="partner" value=""/>

    <add key="sellerEmail" value=" "/>

    <add key="sellerId" value=" "/>

<add key="notifyUrl" value=" "/>

关于AutoResetEvent可以看下面的文章

http://www.cnblogs.com/bluewater/archive/2006/08/14/476720.html

   string key = ConfigurationManager.AppSettings["key"];
            string partner = ConfigurationManager.AppSettings["partner"];
            string sellerEmail = ConfigurationManager.AppSettings["sellerEmail"];
            string sellerId = ConfigurationManager.AppSettings["sellerId"];
            string outTradeNo = Guid.NewGuid().ToString();
            string url = ConfigurationManager.AppSettings["notifyUrl"].ToString();
            string gatewayUrl = "https://www.alipay.com/cooperate/gateway.do";
            //
            AliPay ap = new AliPay();
            DigitalGoods dg = new DigitalGoods("create_digital_goods_trade_p", partner, key, "MD5", subject, outTradeNo, (decimal)money, 1, sellerEmail, sellerId);
            dg.Buyer_Id = "temp";
            dg.Notify_Url = url;
            Session["outtradeNo"] = outTradeNo;
            ap.CreateDigitalTrade(gatewayUrl, dg, this);
            string myScript = @"document.all['discard'].src='displayCard.aspx'";
            Page.ClientScript.RegisterStartupScript(this.GetType(), "myScript", myScript, true);

  protected void Page_Load(object sender, EventArgs e)
        {
            //Session["outtradeNo"] = Request.QueryString["a"];
            AutoResetEvent ansyCard=new AutoResetEvent(false);
            Application[Session["outtradeNo"].ToString() + "Event"] = ansyCard;
            ansyCard.WaitOne();         
           
            if (Application[Session["outtradeNo"].ToString()] != null)
            {

                string s = string.Format("<script language='javascript'>alert('你的充值卡密码是：{0}')</script>", Application[Session["outtradeNo"].ToString()]);               
                Response.Write(s);

            }
        }

 void ap_WaitBuyerPay(object sender, NotifyEventArgs e)
    {
        Card card = new Card();
        AutoResetEvent ansyCard = (AutoResetEvent)Application[e.Out_Trade_No + "Event"]; 
        TradeLog tradeLog = null;

        try
        {
            tradeLog = new TradeLog(e.Buyer_Id, e.Trade_Status, e.Trade_No, e.Buyer_Id, e.Subject, (int)e.Price, 1);
            SNInfo snInfo = card.GetSn((int)e.Price);
            card.WriteLog(tradeLog);
            Application[e.Out_Trade_No] = snInfo.Password;
           

            ansyCard.Set();


        }
        catch (Exception ex)
        {
            //日志
            //
            if (tradeLog != null)
            {

                string t = e.Buyer_Id + e.Trade_Status + e.Trade_No + e.Buyer_Id + e.Subject + (int)e.Price + "sendgoods";
                Log4net.log.Error(t, ex);
            }
            else
            {
                //
                Log4net.log.Error(GetForms(Request.Form), ex);
            }
                       ansyCard.Set();
        } 
    }

.netFrameWork中的异常处理：

一般有个内部辅助类，此类包含的都是返回值是异常的静态方法，此方法根据传入的参数从资源文件中找到异常信息，然后返回给调用者。

调用者不会new新的异常。

不错的处理机制。

如:
下面两个是辅助类中的方法

internal static Exception InvalidConnectionOptionValue(string key)
{
      return ADP.InvalidConnectionOptionValue(key, null);
}
internal static Exception InvalidConnectionOptionValue(string key, Exception inner)
{
      return ADP.Argument(Res.GetString("ADP_InvalidConnectionOptionValue", new object[] { key }), inner);
}

调用者的调用方式：

Public void Demo()
{
    return InvalidConnectionOptionValue(“demoException”)
}

我同意只含有属性（甚至加上CRUD）的Domain Object是不符合OO的，这样做很类似于使用事务脚本和表模块方式，只是把取出的数据再封装到类中。在这种模型下Domain object更像一个DTO和值对象。

同意域模型只包含属性和CRUD没有体现出域模型的本意，域模型实现域逻辑才能称为域模型。从这两点上说Martin的观点也是正确的。

但是总感觉有些不对的地方，毕竟自己和好多人一样用这种模式很久了，能存在这么久也是有原因的，有些人把这归结于ORM（Nhibernate）和DAO模式的广泛使用，确实这两种工具促使了这种模型的发挥范围，但是从本质上说，这种模式是有其优点的，至少我认为他和含有业务逻辑的域模型（充血）比较起来是半斤八两，贫血模型没有比充血域模型差。

      贫血模型的层次结构：
      
      注：domain object实现一些易于绑定控件的接口也可以当做DTO使用，但是一般DTO还是不能省的。图中的ICompare只是一个特例，可能还要实现IList等。
       首先，贫血模型虽然不OO，但是毕竟把数据封装到类里面了，这样就为Service层实现OO打下了一个基础，要比表模块和事务脚本好很多，从这点上看他也不等同于事务脚本和表模块。

       其次，把业务逻辑和域模型（贫血）分开是有优点的，至少把业务逻辑和业务数据分离了，虽然在理论上这种分离是没有意思的也是非OO的，但在实践中这样做至少分离了变化，实现难度也没有增加，为什么是不可以接受呢？难道只是因为他不OO？

       再次，特别简单是这种模型流行的基础。如果使用nhibernate等ORM工具，很容易再第三方工具的配合下生成代码，如果把CRUD从域中提取出来可以更方便的使用代码生成。如果自己些映射可以很容易的在数基层实现Mapper或者用ActiveRecord。

再加上在简单的应用中Domain object可以当作DTO使用，这些都是贫血模型存在的理由。

他的缺点是导致服务层太庞大了，这一点可以把服务层拆分，然后再在这些细粒度的服务层上面封装一个thinService层来解决。

另一个缺点是，我直觉上认为在领域对象中不包含领域逻辑是很不合理的，但是又找不到他不合理的证据。

充血结构：

   包含域逻辑的域对象（充血）没有上面说的两个缺点，他符合OO，很容易实现一个thinService，感觉上这种模型很好。

首先，域对象包含了操作，是真正的域对象，域对象可以重用了,只是听起来很美。

其次，服务层很薄（只包含跨多个域对象或者第三方逻辑的封装），把域逻辑分离了一部分给域对象，变化容易控制，修改也容易。

但是这些优点，很多都是直觉上的，因为业务逻辑太复杂了也太容易变化了，这就造成让域对象包含操作也不是一个很合理的方式。

缺点是实现很难，即使用ORM工具也很复杂，更不要说自己写映射层了。

总结：业务逻辑和业务数据耦合在一起是合理的，但是业务逻辑相较于业务数据是更易变的，从分离变化的角度来看是有必要把他们分开的，也就是贫血模式。同样把DAO从域对象剥离出来也没有什么必要，因为两者都是相对稳定的。
所以我认为贫血的模型是比较实用的。

设计模式是为了解决某一类通用问题而总结出的比较合适的解决方案，整个解决方案都是基于OO，每一种语言的特性不同，解决方式也有区别。说是合适的解决方案是因为，他们提供了灵活性、可重用性、可维护性，这一切又是建立在低耦合的基础上，模式能在需求变化时，灵活的适应新的需求，耦合度低，修改某个类时，不会牵连到不相关的类，这样就产生了易维护的代码

学习设计模式的方法：

       要认识到，设计模式并不是治百病的灵药，他们就是前人总结的解决某些问题的比较普遍适用的方法，因为他们的通用性，遇到具体的问题，你能得到比设计模式更好的解决方案，而不用管它是不是模式，是什么模式。

       一类问题通常有多个适用的模式，用哪个要自己考虑，从实际问题出发，结合现有的模式和语言的特性（如.net反射），找到新解决方案也是好的办法。

要想想那些解决方案为什么会成为模式，用模式为什么会比不用模式好,好在哪里，只有经过这些思考才能更深的了解设计模式，而不去套用模式而是从实际问题出发，去寻找合适的解决方案。

设计模式不是什么高深的东西，不应该去仰视他，而应该俯视，把他踩到脚下，他就是前人的总结，我们完全有可能比前人做的更好，因为我们面对的是具体的问题。

学习设计模式是为了解决问题，而不是为了学习而学习，我觉得学习过程是：

1、      看书，看实际例子，虚拟的那些没有太大帮助，道理谁都懂。设计模式就像画笔，只有到了画家的手里才能画出好的作品，而虚拟的例子就像是拙劣的作品，任何人都会画。

2、      体会，体会为什么要用模式，不用又如何。

3、      运用，一开始就套用，也不用管是否合适，这样就会发现问题，通过解决问题，才能加深理解。这时候不用去想“重构得到模式”之类，还没有到那一步。如果精通了，重构时也没有必要去得到什么模式，那样不是画蛇添足吗？本来问题已经完善的解决了，还要模式做什么呢？

4、      体会，体会设计模式的本质，他们共性的东西，为什么会产生设计模式，改进设计模式。

5、      融合，融合你知道的模式，遇到问题想解决方案，而去理会它是否是模式。（无招胜有招，哈哈）

整个是曲线上升的过程，要反复的体会、运用。不要掩盖自己的缺点，要暴露出来，这样才能提高。

如果说设计模式都体现了几条设计原则（OCP、DIP等），那么设计原则又是什么的体现呢？因此要思考些本质的东西，而不要只看表现，设计中没有任何东西是死的，如果要把这些看死了，认死理，就没有必要在看设计模式了。

       只是有些公司很短视，经常看到要求精通某项新技术之类的招聘信息，其实只要不是脑子有问题，给一个月的时间，基本上都会掌握那些所谓新技术（当然水平也一般，但又有多少用到更深的东西了？），但是要些出好的代码却不这么容易。

       据说，有干了几年的程序员还在写垃圾代码，这些人可能一直在追新技术，出来一个学一个，可是好多重要的东西都丢下了。我以前也一直紧跟MS脚步，现在已经觉得那样没有什么意义了，好多东西需要沉淀。前一段时间想去一家公司，我同学正好负责另一个部门的招聘说不要三十岁以上的，对这家公司的印象大大折扣。

为什么要用设计模式：

我认为是为了写好的代码，好是指：能灵活适用需求，易于维护，最后是重用。设计模式不是为了解决技术细节上的难题，如修改一个语句的bug，模式对这些没有帮助。发展到今天，做应用开发的，已经很少有细节上的难题了，遇到问题可以去MSDN，google，去看相关的开源项目，再不行，请教某个高手。这样一来，培训几个月，谁都可以去写程序了。

但是要想写好，就必须要学习设计模式，学习设计，这需要自己用心体会，实践。不能通过MSDN，google，请教高手得到提高。必须经过自己的努力。

做开发，可以不用设计模式，但你要知道设计模式所带来的好处。这些好处在维护旧代码，需求改变时最能体现，见到垃圾代码真有去砸机子的想法，而设计好的代码就好多了。

设计模式主要是解决设计中的僵化性，脆弱性，粘滞性。这些特性都是在变化中体现的如果没有变化，也就没有了运用设计模式的基础，也没有必要用OO了。

设计模式的语言相关性：

设计模式主要用到的是抽象、多态，抽象和多态可以用继承实现，也可以用函数指针实现（.net委托），所以有些模式既有继承的实现方式也有委托的实现方式，哪种实现合适和语言特点、问题相关。还可以用配置文件、反射（.net）机制实现设计模式和设计的灵活性。

设计中的几个问题：

设计模式更注重于可复用的结构设计方案，而框架更注重具体问题的设计和实现。

针对接口编程，而不是针对实现，这就要求在类层次的顶端是接口或者抽象类。

让类的调用者去时刻记着去检查错误码是愚蠢的想法，因此要尽可能的使用异常。

我一直觉得设计模式，设计，一直在解决耦合性的问题。如果达到了合适的耦合就是很好的设计。（不知道对不对）