园子很久没更新了啊 园主是否转战其他平台了啊 有知道的么 给个关注链接呗

请用backbone

不错的框架，值得学习

不错 mark~

教程打不开，视频也不能下载了，请博主修复

激动了下，说错了，但是bug还是存在。 p.ParameterName = paramPrefixToken + paramNames[i].TrimStart(paramPrefixToken); 改成下面的才行。而且是好几处。 p.ParameterName = paramPrefixToken + paramNames[i].TrimStart("@:?".ToCharArray());

NBearLite在 SqlQueryFactory.cs中有一句话，我觉得是bug. p.ParameterName = paramPrefixToken + en.Current.Key.TrimStart(paramPrefixToken); 我修改成了 p.ParameterName = paramPrefixToken + en.Current.Key.Remove(0, 1); 因为我在mysql进行测试的时候，发现 @test，最后变成了?@test.

博主你好 请问您 在EntityDesigns类库里的interface类有没有一个标记让插件不要在Entitys里和EntityConfig.xml自动生成的属性呢？意思是 数据库的相应字段可以自动生成 那么我再想在这个接口里添加自己定义的方法属性就不要自动生成了

@山顶洞人 CallServer(inputcontrol,context) 参数跟GetCallbackEventReference的参数名称不一样。arg，inputcontrol :)

@山顶洞人 function CallServer(inputcontrol,context) { context.innerHTML="加载中"; arg=inputcontrol.checked; <%= ClientScript.GetCallbackEventReference(this, "arg", "ReceiveServerData", "context")%>; }

学习！

good

good

请教一下，我在使用emit时出现的错误： 用户代码未处理 System.Security.VerificationException Message=操作可能会破坏运行时稳定性。 Source=Anonymously Hosted DynamicMethods Assembly StackTrace: 这个问题该如何修复？或者是否需要修改些什么配置？

不知teddy的NIntegrate有没继续开展下去。关注中

非常感谢teddy为开源框架所做的贡献

NIntegrate是什么来的？nbear的后续版本？

我们的XCode是一个充血模型的Orm，基本上就是你所提到这种模式。 说它会保持数据库连接，那纯属是胡乱猜测！ 实际上，实体类有个特性记录着连接名ConnName，需要执行数据库操作的时候，才调用DAL.Create(ConnName）得到一个DAL，它自身根本就不会保存DAL的实例。 不操作数据库的时候，它跟数据库一点连接也没有！ 如果做客户端，实际上我们会做点手脚，直接把实体类的那些静态方法给暴露给客户端，这些方法可都是业务方法，而不是大多数人那样暴露数据操作方法。

在routingservice中提供了IRequestReplayRouter,ISimplexDatagramRouter等四个router接口，现在如果我的Service接口里定了一个operationContract的isOne-way=true,而另一个operationContract为false,此时我应该怎么使用那四个router接口？irequestreplayrouter不可行，而ISimplexDatagramRouter也不能兼顾到两个operationContract.请教各位如何处理，谢谢！

YetAnotherForum.Net最

“简单来说，如果要Stub或Mock一个方法，Stub指的是，为了测试，手动写一个相同签名的方法，根据我的测试需要，对给定的输入参数，返回一定的输出；而Mock则借助一定的框架组件，自动生成一个方法的实现，对于给定的输入，返回一定的输出。” —————————————————— 这段的意思是：Stub和Mock的区别在于前者是手工写的，后者是借助框架？如果是这样，我不同意。 我的理解：UT里分“测behavior”和“测state”两种，Mock是可以对行为进行验证的，Stub则只能对状态进行测试。

太遗憾了，以前做项目都没用过正式的ORM，只是写Sql，感觉这样更快

@Teddy's Knowledge Base 单元测试也基本上就限于简单输入->(复杂)逻辑处理->简单输出 这种场景，复杂点儿的，也就在理论上玩玩，用起来都是鸡肋。 单元测试，说白了就是把白盒测试细化、提前到开发阶段，开发人员构造输入，校验输出。这东西也有很大的局限性，只是宣传的时候都扬长避短，被吹玄了。

这种问题其实都可以折中的，但是个人认为大部分情况还是不建议这样使用，提高业务服务器的性能方式有很多，牺牲安全这个不可取。其实先这种可以用OData的方式来实现还是不错的。

@Teddy's Knowledge Base [quote]Teddy's Knowledge Base： @Galactica 业务逻辑放到客户端，对于大型的Web系统来说，其实基本上是不可避免的，为了降低服务器的压力，尤其是提高scale的能力，一部分业务逻辑在web端其实是很常见的，甚至可以将一部分不太敏感的业务逻辑放在浏览器的客户端js。不过，本文想表达和讨论的，并非业务是否可以放到客户端的问题。我想讨论的是，像Find(Criteria criteria) 暴露给客户端的数据库的语义（我觉得一定的数据库语义不一定就算是业务），你也可以将criteria理解为一个linq语法的查询。这也不表示，criteria是没有限制的任何查询条件，criteria一般不能随便构造，比如简单的new出来，用于构造出criteria的辅助类上是可以做一些约束的。 当然我文中也提到了，像Find(Criteria criteria)这样给予客户端太多灵活性的接口对很多应用场景是不合适的。但是，是不是应该可以有一些应用场景是合适的呢？[/quote] 我觉得用在公司内部比较合适,如果给第三方使用的话,还是使用基础服务、组合服务和流程服务的SOA分治模式比较好。

@Teddy's Knowledge Base @Galactica 有一个问题是很明确的，对于数据驱动应用的场景（很可能是大多数），开发人员干的活本来就是决定在各种条件下暴露什么不暴露什么。否则的话，任何一个真正熟练操作Excel的白领MM我看学会一定难度的SQL去操作更大规模、更复杂的数据都不成问题，要开发人员也就没有什么用了。 所以关键在于，掌握好这个度。灵活性越高，开发人员维护起来就越容易；不跨过界，就不会产生附加的问题。不过其实只要那个白领MM不能决定“暴露什么不暴露什么”，饭碗是一定能保住的。

个人觉得 activerecord 序列化还是不错的 写dto和相关的的model转dto太麻烦了 还不如在model上定义呢。 至于查询条件放到客户端是不是不太灵活 因为有些find可能需要特殊处理 比方有些find需要缓存 有些find是直接查询数据库

@Galactica 业务逻辑放到客户端，对于大型的Web系统来说，其实基本上是不可避免的，为了降低服务器的压力，尤其是提高scale的能力，一部分业务逻辑在web端其实是很常见的，甚至可以将一部分不太敏感的业务逻辑放在浏览器的客户端js。不过，本文想表达和讨论的，并非业务是否可以放到客户端的问题。我想讨论的是，像Find(Criteria criteria) 暴露给客户端的数据库的语义（我觉得一定的数据库语义不一定就算是业务），你也可以将criteria理解为一个linq语法的查询。这也不表示，criteria是没有限制的任何查询条件，criteria一般不能随便构造，比如简单的new出来，用于构造出criteria的辅助类上是可以做一些约束的。 当然我文中也提到了，像Find(Criteria criteria)这样给予客户端太多灵活性的接口对很多应用场景是不合适的。但是，是不是应该可以有一些应用场景是合适的呢？

Find(Criteria criteria) 这种东西根本就不提倡，你等于是把业务逻辑又放到客户端了，我先不说设计上的缺陷，我只说商业上的缺陷，这样的模式，就是告诉客户，我们只要给你一份数据库表结构，你就可以随便查询了，那你怎么挣钱？怎么防止盗版？所以，正确的做法，就是要让客户知道，你买我的软件，只要我们公司倒闭了，你就无法继续使用。所以，客户应该持续支付年费，而非一次付清。

Teddy兄，注意身体啊！ 说说文章吧，文字很精练，赞！不过对于最后一点，我倒是有点不赞同，我觉得有些模式确实在某种程度上弥补了语言表达能力的不足。因为Java没了指针，那么相应的函数指针也没了，尽管更容易写出健壮的程序，但这是以损失灵活性为代价的。那么，设计模式是不是一种补救手段呢？

@LanceZhang "要考虑各方面的成本，和是否真的有应用此模式的必要" --你说的没错,事实上over design还算好的,至少还是解决了问题,别人也还能理解,也还能重构回来;最怕就是盲目套用,把本来能说明白的东西,弄得说不明白了,到头来迟早要用大得多的成本来反工.

[quote]倪大虾： 这点不同意.TDD最大的好处应该是作为一种设计手段体现的,用来反复验证软件是否存在严重的逻辑问题,而不会去关心细节. 简单的说,TDD是用来测试接口的,做TDD的时候接口可以没有完全实现.[/quote] TDD可以用来规划漂亮的，自然的外部接口（fluent api）， 从设计初期就开始关注外部逻辑的展现形式，同时可以促进内部的实现。 我目前在写一个template engine， 但是我不知道该如何做一个high level的design，这个我就从我希望它怎么样被使用一步步开始。 比如我只知道我想实现“不引入新语法，使用html的语义化作为绑定的表达式。”， 我就可以先规划外部的api，然后进而驱动出一个design。 test1: "<div><label for='username'>UserName</label><input name='username' type='text'></input><lable for='blog'>Blog</lable><input name='blog' type='text'></input></div>".AsHtmlTemplate().Bind(new { UserName='dayi',Blog='http://walkingboy.cnblogs.com'}).RenderHtml(); 我可以预期它的最终实现是什么，写个Assert，然后继续下一个test。 "<ul><li><span name='username'><span><a name='blog'></a> </li><li><span name='username'><span><a name='blog'></a></li></ul>".AsHtmlTemplate().Bind(new []{new {UserName='dayi',blog='http://walkingboy.cnblogs.com'},new {UserName='teddy',blog='http://teddyma.cnblogs.com'}}).RenderHtml(); next..... 最终就能驱动出一个好的high level design。

[quote]Teddy's Knowledge Base： @msnweb 可能还是我的表达能力不太好吧~~ 一个好的布道者,的确应该既对技术有深刻的理解,还要是一个好的作家,甚至是一个好的哲学家。[/quote] 可惜现在国内大部分流行“实用”主义、理论无用论，觉得这些都是虚的，没用。其实理论指导才是最根本的。 所以讨论“理论”层面的东西的时候，好多人都开始“喷X” ^_^... [quote]生鱼片：design pattern只是对常见问题的一般解决方案，它并不是什么圣经类的东西，使用它必须 要先理解其深刻的内涵，之后你就可以忘记它，当你在遇到问题时你给出的解决方案自然就是各种模式的产物了。[/quote] 认可，只有忘记了，才真的理解了，因为你已经转化为经验，转化为自己的东西。 一开始看书，看代码，只是入门的方式。

@Tristan G 卧床在家,没别的事可做,只能写写博客了~~ 没错,在我看来GoF也是给设计师看的.junior或者middle级别的dev,如果我面试,能完善地写出singleton,我觉得已经能接受了.不过很遗憾,即使综合能力达到middle的dev,singleton能写出一个能编译的,可能只占六成,能考虑到线程安全的,顶多1成.

大家都推崇GOF的书，其实我觉得GOF那书对于初学者来说看了可能会晕，不知道是不是翻译的问题，可能是我太愚钝了，我的设计模式启蒙是从Java与模式开始的

生病了还在家写博客........

@msnweb 可能还是我的表达能力不太好吧~~ 一个好的布道者,的确应该既对技术有深刻的理解,还要是一个好的作家,甚至是一个好的哲学家。

[quote]Teddy's Knowledge Base： @msnweb 抽象的概念的确没有具体的实例来的容易理解,但是往往正是没有理解Design Pattern的本质,才造成觉得Design Pattern深奥.[/quote] 我更愿意相信 是描述的刻意抽象造成了新手的理解困难。不知道是表达能力还是描述角度问题，很多简单的理论总会被描述得非常复杂。就像设计模式。 而国外很多书，描述得却是非常细致，行语非常简单，理论很清晰。这才是实质，这才是本质。

老马最近写作热情很高啊

知道周芷若为啥选择练《九阴白骨爪》，而不选择练《九阴真经》吗》？因为后者可以速成；知道欧阳锋为啥选择练《九阴真经》，而不选择练《九阴白骨爪》吗》？因为他想做武林至尊。 这个强

@msnweb 抽象的概念的确没有具体的实例来的容易理解,但是往往正是没有理解Design Pattern的本质,才造成觉得Design Pattern深奥.

我觉得写得不错

想要实现 Galactica 所说的《九阴真经》，还不如看看《反面模式》，速成、让人少犯错误、不误导。 反面模式 [url=http://zh.wikipedia.org/zh-cn/%E5%8F%8D%E9%9D%A2%E6%A8%A1%E5%BC%8F]http://zh.wikipedia.org/zh-cn/%E5%8F%8D%E9%9D%A2%E6%A8%A1%E5%BC%8F[/url]

现在谈到Design Pattern，恐怕一多半人就直接跟GOF23联系起来了，觉得pattern是个好东西，潜意识的能用必用。但很多情况下patterns并不能直接被套用，就算能够部分套用，也要考虑各方面的成本，和是否真的有应用此模式的必要。 如果能用则用，为了让代码结构“优雅一点”便滥用只能造成OVER DESIGN——到头来重构起来更麻烦，还不如不design。 支持微软的叫法：Patterns & Practice

design pattern只是对常见问题的一般解决方案，它并不是什么圣经类的东西，使用它必须 要先理解其深刻的内涵，之后你就可以忘记它，当你在遇到问题时你给出的解决方案自然就是各种模式的产物了。

看了你的文章 我更加不理解了。 你把深奥的概念说得更加深奥了。 orz. 设计模式就是一些典型环境的典型设计方案。 类似于牛顿第一定律 第二定律。 合适的环境套用这个公式就可以了。 但是请记住牛顿定律也不是万能的。 设计模式是一些常用的思想，但它不是神更不是万能药。找合适的场合用用就可以了。

赞一个。GOF写的设计模式太过书面语言，不容易懂~因此，我看的是Headfirst的《设计模式》，以及Alan Shalloway的《设计模式解析》，其中有一点，使我印象深刻，就是在设计类的时候，一个比较重要的原则就是，类是有生命的东西，应该按照类的职责来封装方法。

顶！以前刚开始接触OOP时把Design Pattern看得跟神一样，后来也慢慢地开始认识到，它不就是和它的字面解释一个意思么，只是一些Pattern，核心还是OOP本身~~嘿嘿

@Galactica 你这个推论我还真无语了～～

@Teddy's Knowledge Base 你又误导人，知道周芷若为啥选择练《九阴白骨爪》，而不选择练《九阴真经》吗》？因为后者可以速成；知道欧阳锋为啥选择练《九阴真经》，而不选择练《九阴白骨爪》吗》？因为他想做武林至尊。