jhh0111

有点无知,有了几个项目了,加上mvc感觉很好,全新的开发模式,快速高效

书哪里有下阿

Linq to sql看过,做过几个小东西,感觉用得不是很顺手,所以就没有再用,还是用强大的SQL了

Linq只用了反射中partial trust的部分，性能损失可以忽略

--引用--------------------------------------------------
matta: 楼主,你对linq to sql太无知了.
"性能问题
这个就不用说了，通过反射来实现的，当然有损失，也能接受，
"

这是你自己想当然的吧.好好认真了解了再写评论吧.
--------------------------------------------------------
请问，如果不通过反射的话，那它是通过什么方式实现的？

@陈文锐
这就完了，只读的字段当然就只读了，那么既然如此，你如何把数据库中的数据通过linq to sql赋进去？

add是给实体增加，内存中进行，InsertOnSubmit是写库，很容易理解。

写的很好 赞一个

爱死linq to sql了，开发速度那个快啊， 复杂的业务逻辑也没问题，我们都做了无数个项目了，呵呵

楼主,你对linq to sql太无知了.
"性能问题
这个就不用说了，通过反射来实现的，当然有损失，也能接受，
"

这是你自己想当然的吧.好好认真了解了再写评论吧.

如果关键字段是readonly的话，你有何妙招赋值,只读的字段当然就只读了。你还赋值？

我想学linq该怎么学啊。*

问题的(1),(2),(3)你还可以在网络上好好找.有解决的方法的.TimeSpan字段问题是在beta版时问题比较严重,在正式版本中就得到比较好的解决.使用

PersonalInfoManager事例.我不记得地址拉.你可以搜索一下.Attach(object, bool) .

观望中

没有完美的技术～
存在即合理
在一短平快的项目特别是WEB项目，我还是首选linq2sql.

那LINQ TO SQL做一些DEMO给客户看还是可以的

你应该是刚体会到orm这类框架.仔细再清楚内部如何实现,你就明白了.这种做有他的道理.

无论什么东西都没有完美的吧.http://www.lifeye.com.cn/

正在做LINQ的项目 感觉一般简单的查询linq确实可以用强大来形容 但是如果业务复杂的话 linq并不值得推荐 这只是本人个人观点 。。。

前景肯定是有的，无非是道路崎岖点。要在快速开发与性能高效之间做出正确的选择。不要盲目是指既不要盲目相信，也不要盲目不相信。戏言无怪！

linq to sql是linq to XXX的一个运用而已 ，要在项目中使用微软提供的ORM解决方案，还是用Entity Framework。

@陈文锐
能不能说得详细一点，如果该字段是readonly的话，请问反射如何对该字段赋值？在我的测试过程中，这将引发VerificationException.

（2）该实体的所有实体存储字段都不能有readonly关键字（反射要对该字段写值）???? 我很怀疑你有没有认真去了解过。

LINQ TO SQL，大型场景不可能，小型的连SQL数据库都用不到，在我去年学完它后就扔掉了。LINQ实用的部分只是TO XML和TO OBJECT，再加上TO DATASET吧

@楼主:
Attach有另外一个重载：Attach(object, bool)
其中bool参数指出是新的还是旧的
另外好像其它子对象不需要Attach，前提是这些子对象的属性上有合适的标记，不太记得了，不对请批评。

@EntLib
虽然还没有看Linq to XML, 但是Linq to Object还是很好的，我觉得这是Linq的最大的价值。

不错！！！ 写得很好！

不过， LINQ TO XML / LINQ TO OBJECT 还是值得一用的。

LINQ的确是有不足的地方

linq 无法自动检查到数据库里的变化 很讨厌

@乐子哥
1,部分类能解决部分的问题，但是没法解决所有的问题，比如，如果EntitySet提供的功能不足以满足父对象对该集合的功能需求时，怎么办？你没法替换EntitySet，也没法继承EntitySet，因为它是密封的。

2,这个问题，就像我说的，需要了解DataContext内部的运作方式后才能知道，简单的说，Attach方法是将该实体置于DataContext的跟踪之下，它要求数据库中已经存在了该实体所对应的那一行，而不是直觉上感觉是往数据库中加一行。

1、扩展性这一块看可不可以做部分类的方式

2、db.BaseTasks.Attach(baseTask);
db.SubmitChanges();
}
结果运行失败，当然我现在知道为什么失败，但这也暴露了一个问题，就是使用者在使用Linq to Sql时，必须清楚DataContext对象的内部运作方式

这个是什么原因造成的，谢谢。。。

不足 += 性能降低.

说的好 我对orm没用过 这次学着用linq 开始十分爽很快就觉着怪怪的，
不知道Nhibernet 怎么样 你说说！！！！！

msdn上这个问题已经说了很清楚了吧。。。

说的不错，不过有几个小问题：

1、GC查看该对象是否实现Finalize方法（忽略继承自object.Finalize方法）

GC是检查该对象是否有重写Finalize方法，不论是该对象类型重写还是该对象父类型重写，而绝对不是该对象是否实现，因为Finalize方法并不是抽象的。



2、正确实现Finalize方法就能够保证托管资源得到正确释放，内存泄露不会发生。

必须实现Finalize方法如果在你的类型中分配了“非”托管资源，否则必然会造成非托管资源不能被释放，因为GC管不到非托管资源。

IDisposable作为一种友好的接口，在分配非托管资源的类型中是可选实现的。



3、但，我们发现，Dispose方法比Finalize方法多执行了“清理托管资源”这部分内容，这是为什么呢？为什么Finalize方法不能执行“清理托管资源”这部分代码呢？

Dispose方法不是为托管资源准备的，托管资源的释放只能由GC来执行。Dispose方法是提供一种途径提前释放非托管资源，正因为此，即使Dispose方法调用其他对象的Dispose方法也是释放其他对象的“非”托管资源而不是托管资源。

准确的说是Finalize不能使用托管资源，譬如说托管堆上的对象。

学习了

@TONY.chen
对象不可达，简言之就是该对象不被其他对象所引用。GC进行垃圾回收，会根据根对象进行遍历，从而找出所有的可达对象和不可达对象，然后对其中的不可达对象，也就是垃圾对象进行内存清理。这种算法一般称为“标记-收集-紧缩”算法:-)

1、GC发现一个对象（该对象不可达）已经成为垃圾

"对象不可达" 这个如何理解??

浅谈什么是䅄�模式。

其实Framework Design Guideline里面说得很清楚了。

这是官方的原理吗？

不过正确的 IDisposable 写法 msdn 已经给出，和博主的类似

p=null可以让gc进行收集，但如果之前将p加到了list之类的地方的话就没法收集了
对于string有特殊的intern机制，所以估计不会立刻回收，但也能保证不占用大量内存

o(∩_∩)o...，我说下我的理解：
1.public class CaryClass: IDisposable
{
~CaryClass()
{
Dispose();
}
public void Dispose()
{
// 清理资源
}
}

这种写法只是为了说明将所有清理代码保留在一个位置，以避免代码的重复。

2.托管堆分配的任何内存垃圾收集器都可以确保将其清理，但垃圾收集器却不知道托管堆之外分配的内存如何清理，比如垃圾收集器不知道如何关闭一个文件句柄，以及如何使用 API（如 CoAllocTaskMem）来释放在托管堆之外分配的内存。所以才需要重写 System.Object 的 Finalize 方法（提供析构函数）来实现，使垃圾收集器知道该对象希望参与其自身清理，这样只是让Object的Finalize方法来调用Dispose，但是这个Finalize的运行是不确定的，所以才有了IDisposable模式来手动调用。这样可以尽量保证当对象不可用时尽快释放资源。

3.由于析构函数不再承担对象成员的内存释放，所以你下边说的Finalize方法就不能调用components.Dispose（）方法以及顺序问题我也是这样理解的，其他的好像都差不多吧。

最近遇到了内存方面的问题
操作解析xml,然后存取数据到数据库,用下面的两种方式,内存都会不停的增大
在其中gc.collect也没有用处...
1.
foreach()
{
Product p=new Product();
p.title="ddd";
p.desc="ttt";
Dosomething(p);
//p = null;
}

2.
Product p=new Product();
foreach()
{
p.title="ddd";
p.desc="ttt";
Dosomething(p);
}

我想知道最后赋值p=null能不能让gc收回内存?第二种方式p.title重新赋值后,以前的string会不会及时回收?谢谢:)

这个家伙太NB了.
hi.baidu.com/wangdei1
hi.baidu.com/wangdei2

wangdei.blog.sohu.com/ wangdei@sohu.com
http://5a520.blog.sohu.com/ wangdei163@sohu.com

blog.sina.com.cn/wangdei wangdei1982
blog.sina.com.cn/bt520bt285 wangdeiwangdei
wangdei163.blog.163.com/ wangdei163
wangdei164.blog.163.com/ 　wangdei164

wangdei.blogcn.com/index.shtml wangdei
i.mop.com/wangdei/blog wangdei
blog.myspace.cn/1306947992 wangdei
wangdei.blogbus.com/ wangdei
blog.tianya.cn/blogger/view_blog.asp?BlogName=wangdei wangdei163

@没有昵称

可能我没表达明白我的意思，我当然知道short，int在内存的表示，我要探究的就是编译器是怎么处理我们的代码的。

比如 float _float = 5.0;
如果有“足够聪明”的编译器的话，这行语句就不会无法编译通过了，但我们发现C#编译器无法编译通过。

当然，我也不是说C#编译器不足够聪明，这就是我前面这段加引号的原因，因为要做到类型安全，尽可能的在编译阶段发现潜在的问题，是有好处的。

因此，我考虑的是，像 short _short = 10 这样的语句，编译器是怎么处理的，是不做溢出检查的直接生成IL代码（如此则代码存在溢出隐患)，还是生成在IL代码中做溢出检查的IL代码（如此则有性能损失）。当然，最后我搞明白的是，这两者都不是，编译器在编译过程中做溢出检查，最后的IL代码是不做溢出检查的，这样，就即没有溢出隐患，也不会有性能损失(这个结论才是我最后需要的，而不是我不懂汇编，没有从机器的角度思考问题，实际上，我用80*86汇编写过完整的代码，怎么可能会不知道汇编）。

在没有做上面测试前，我问你，short _short1 = 10; 与 short _short2 = (short)10; 这两句，哪句性能更好，哪句安全性更高（或者说隐患更少），你会怎么回答。

实际结论是，都一样。

和楼主一起学习。

short b = a编译不通过的原因，是a是整型，整型的取值范围大于short，将a的值复制给b时会造成截断。所以编译器会产生一个错误，要求你使用强制类型转换。实际上也就是提示你：你应该在代码中保证a的值在short类型的取值范围内。否则试想，如果a = 32768，你执行b = a，你觉得b的值会是多少？

short b = 10能够编译通过的原因，是编译器知道10是一个有效的short值，在-32,768 到 32,767之间。如果你写了一句short b = 32768，仍然会出编译错误。

至于你怀疑为什么short b = a不行而short b = 10却没问题，可以看出你有个基本概念不清楚：虽然a = 10，但这两句话是绝对不一样的。第二句话产生的cup指令是“将常数10 赋值到b所在的16位内存地址（因为是short）上去”，而第一句产生的cpu指令是“1、从a所在的32位（因为a是int类型）内存中把数据读出来；2、把这个数值复制给b所在的16位内存地址上去”。

因此可见你对汇编的知识已经忘的差不多了吧。在编程的时候，要用计算机的思维方式去思考，而不是用人的思维方式去思考。

既然你已经在观察IL代码了，那何不观察一下short b = a和short b = 10所产生的IL代码有何不同？

可参考：http://www.codeproject.com/KB/cs/LocalizingEnums.aspx

嗯。看了，也理解了。
我又想到了一个问题，有时候一个ComboBox中供选择的枚举值并不是某个枚举的所有枚举值，而只是一部份，这样的话就不能直接
this.comboBox1.DataSource = new EnumDataSource2<Sex>();
而需要手动构造你的EnumAdapt类。

我觉得可以为EnumDataSource添加一个构造方法
public EnumDataSource2(params EnumType[] @enums)
{
if (enums == null || enums.Length <= 0)
throw new ArgumentException();
foreach (EnumType value in enums)
{
base.Add(new EnumAdapter(value));
}
}

以满足这个需求