LoveCherry

兽交了，LZ神人啊
晕，怎么我输入法第一个是兽交啊，应该是受教！

呵呵，的确很资深

在SubSonic之前也看到过buildprovider做orm的demo，但是SubSonic对作者把它做成了产品

@听者
可以MSN上问我要代码

我在卖 http://auction1.taobao.com/auction/item_detail-0db1-b3932d6e3504ef229675c1e365717b53.jhtml

@听者
可能是光盘损坏可以加我MSN直接把压缩包传给你

@EagleFish
人处的环境不同，想的也不同。我在西雅图仅仅一周也会怀念中餐和汉语，但是回来之后到邮局拿包裹就马上遇到有人插队，我说请排队就和我吵，当然很不爽。

@Autumoon
明年三月有

@T2噬菌体
我是初学者，不可想象LZ还是学生，能有这样的思考层次并且愿意分享前途一定不可限量，我在LZ这个年龄的时候还只知道打游戏浪费时间呢。

在这里对象适配器还是比较合适的，如果需要扩展对被适配类行为的话可以考虑类适配器，一般来说优先考虑组合而不是继承

扩展方法的确非常有价值，有了它一些设计模式的意义就不大了

从接口讲到适配器模式，很清晰

sp1234？

Lz和lz的代码中体现出了纯真，支持你

比起直接用SQL获取总价来说，我们的方法少了一次数据库的往返。

是2次吧，而且还要因为聚合进行一次完整的数据信息获取

盛大？？

如果有预约并且邀请函到手的话，3天即可，否则肯定来不及

活雷锋

这个？

@怪怪
说的很好，支持你这种风格

客户端A、业务层B、数据库C，考虑一下，假设A和B分开部署，也就是分布式的情况
由于C关系型数据库中数据扁平化，B给A的时候需要序列化，也需要DTO扁平化、轻量化，而且加上A/B以及B/C之间是网络传输，应该尽量减少数据的加载量。 这样相当于一个气球，中间捏了两截，对于WEB程序来说，如果不涉及到数据持久，A和B可以是非常OO的，我们不需要考虑立体数据的扁平化，对于需要持久，那么A、B就非常尴尬了，直接利用PO施展OO的时候收到诸多限制（又要OO又怎么减少数据量、怎么兼顾表现层等）。WEB环境和数据库环境支持高并发，搞的不好由于业务层没有做好多线程还可能产生数据不同步，并发量不高的问题，在分布式环境下ORM的实施难度又高了很多（还有麻烦的若干O的转换问题）。
其实传统的ADO.NET挺好，A/B/C之间是线性的，一切都是这么合理，对于业务不是很发达的项目是最好的。其实，我们传统的做法中有很多合理的地方，往往有很多人对某些知识熟悉之后会否定简单而正确的东西，搞出一些复杂而又很要命的设计，绕弯给自己找不痛快。我始终觉得，领域领域，当我们的领域真的很复杂的时候（不是项目的复杂），是可以考虑ORM、DDD的，但是如果业务不复杂的话，没有必要追求这些东西（很有可能会因为ORM把时间浪费在一些难缠的问题上而大大降低生产力）。我们是希望ORM来帮我们解决数据持久化问题，而不是让ORM给我们找麻烦的。
我是这么考虑的，两种用法。要么把ORM当作一个工（玩）具，纯粹用来简化SQL语句的评接等工作，不要为复杂的业务对象怎么持久化到数据库中费脑子了（如果先有数据库的话的确很费脑子），自动生成的实体直接做DTO了。要么就是设计一个比较理想的领域对象，在业务逻辑中尽情使用领域对象提供的多态性，在数据持久化的时候才去考虑怎么把这些对象保存在数据库中（可以稍微放松一下范式），在要传输给表现层的时候，转化为一个面向表现层优化的（可以一次性传输一个页面上需要的数据）的DTO，在业务逻辑中还可以做一些业务对象的缓存等等。当然，这种情况是针对领域非常复杂的项目，如果是新闻系统的话，你就会发现除了DTO、PO、VO之间的转换之外我们什么都没有做。

直接获取对象ID即可

呵呵，看看 beta2 到 正式版的改动就知道了

这不是我写的书中的一部分吗？

看了一遍，的确八九不离十，到用的时候统统忘记。我觉得这样的一条一条，意义不大。而.NET的源代码中有很多体现类似设计思想的，可以拿过来举例

@jillzhang
编译器做了很多工作，隐瞒了很多事实，真不知道是喜事悲

多路广播委托派生于System.MulticastDelegate

－－－－－－－－－－－－－－－－

应该淡化多路委托这个概念吧，现在有纯单路委托吗？

注意：委托的声明位置在namespace里面，类的外面。
？？？？
虽然文中有一点不确切的地方，分享精神值得鼓励阿

简单了一点

@Damon King
你靠URL重写也能办到阿

@airwolf2026
邮件中的问题我全部回答，大概已经回答了100个问题了。
blog的问题要看，如果是佷玄乎的问题就不回答了。

除了ASP.NET揭秘居然我都有了

http://www.cnblogs.com/lovecherry/archive/2008/03/25/1121225.html ASP.NET MVC In-Depth: The Life of an ASP.NET MVC Request 的翻译

1、Jeffert Richter的《CLR VIA C#》，中文版翻译质量一般，建议读原版。此书实在是精炼，每一小段话可以回味很久。（可以配合《C#和.NET实战：平台、语言与框架》（好像是园子里面的人翻译的，中文版应该不错）一起阅读）
2、GOF的《Design Patterns》中文版翻译质量很好。内功心法级的书，自己实践加上书的点拨，每次读都会有心得。（可以配合《Agile Software Development》（没有读过中文版，不知道翻译得怎么样）一起阅读）
3、Martin Fowler的《Patterns of Enterprise Application Architecture》中版翻译质量不错。虽然有很多议论，但是还是值得一读，对于设计理念的扩展有帮助。
我想这基本书就算读成草纸也不为过吧。

--引用--------------------------------------------------
怪怪: @目标定的太大

难写难写在，脱离了领域，有空谈之嫌； 就某一领域出发，面太窄，也会涉及到领域本身的复杂度。
--------------------------------------------------------
这句话太同意了

调用类的方法时编译器先从类中找，找不到再找扩展方法，再找不到就编译错误。

@实话实说
国外很多40、50岁的人还在搞技术，这种情况的确在国内不多。能与国外的一些大作看齐是我们的目标，国内的图书也可以走自己的风格。而且我发现国内特殊质量不高的原因不是没有能和国外专家水平相当的作者，而是国内出版界和一些作者的急功近利，往往深入的书籍是不被出版社看好的，出版社需要的是能卖的书，有质量的书也是需要长时间来写的，出版社又等不及。《ASP.NET第一步》这本书的确由于自身水平不足，时间不充裕等很多原因，不够细致，也不乏一些错误的观点，但是我确实看到了很多初学者受益，这是令人欣慰的。这位朋友与其贬低别人还不如自己拿出一些自己的作品来和别人分享。

翻译水平已经大于了某些国内技术图书的翻译水平

自己做ASP.NET自定义控件、ASP.NET AJAX扩展控件，使用LINQ TO SQL（包括所有ORM）
对小项目来说是没事找事，费那劲兜个圈子还不是HTML、SQL
做ASP.NET AJAX客户端控件已经算是在客户端兜圈子了，还费劲封装成服务端控件，嫌开发时间太充裕？LINQ TO SQL费劲给你生成出来的SQL代码，跟踪后一看，我靠，这效率太差，不能用！
1983是我的出生年份

这么好的文章被从首页撤走了，我感到痛心

mvc+linq+ado.net ef+silverlight+asp.net ajax+wcf+wf+utility+一系列开源框架 爽阿

架构也就这样了，细节更重要

.NET 3.5出来了一段时间了，下面是我的感受
 ASP.NET AJAX：完全微软的风格，开发难，使用简单。而且AJAX离淘汰不远，不建议学习。
 ASP.NET 3.5：没有什么新东西，可见WEBFORM模型也就这样了。 ASP.NET将朝RIA、更快速开发（数据脚手架）、更自由开发发展。
 WCF： 基本不需要学习，直接用！不过意义不大， WCF不是万能药，原先不行的，用了WCF还是不行。
 LINQ： LINQ TO XXX，LINQ TO object真的有用（学好查询语法就可以），linq to sql是鸡肋，linq to dataset/xml/其它 还是可以用用的。
 WF，ADO.NET 数据脚手架： 用起来简单，要定制一些东西还不如手写。
 SILVERLIGHT： 前途无量， 革命性的东西，不过不到3.0成熟不了。
 MVC： 思想没有什么创新，但是按照微软的风格以后在C上做的文章会很多，按照这个发展看下去应该不会差。
 IIS7： 早晚要用的，而且和ASP.NET结合更紧密了！
所以，我的推荐是 了解一下SILVERLIGHT 2.0（SILVERLIGHT发展的速度令人炸舌，1.0到2.0的变化相当于ASP到ASP.NET！）、IIS7、MVC（继续发展ing）的大概，学习一下C# 3.0（C#不搞好，学什么都是白搭）， 其它技术一概不用理睬（MS AJAX、WCF没有什么意义，没有任何突破性）。

不存在精品不精品的概念，只要是用心写出来的，简单和基础又怎么了？
看到基础文章我一般就跳过，顶多浪费我10秒，别人写也要几个小时吧。

居然被移除了首页，哎！

@zym19
国企我是坚决抵制的

@jinjianjun
可能是忘记了，晕

23岁的老赵

我不在逻辑层直接采用自动生成的实体，而是在数据层通过LINQ TO SQL转化为逻辑实体（逻辑实体可能和数据层的实体差别比较大，1是避免传输和从数据库中获取比必要的数据，2是为表现层的显示进行优化）