Linq to Sql 的具体用法有哪些困惑？
- 内容介绍
- 文章标签
- 相关推荐
本文共计1398个文字，预计阅读时间需要6分钟。
近期终于得以试用Linq to Sql，刚开始使用，感觉还挺简单。也许是我还不太熟悉，所以也有点‘水土不服’。
（又翻出来一篇一年多以前的半成品，赶紧给补充完整放出来。）
最近终于得以试用Linq to Sql了，刚开始用，感觉还挺不错，因为一切都显得很简单。也许是我还不太熟悉，所以也有不少的困惑。别的先不说，只说一个：“有状态的”实体类。
Linq to Sql 所创建出来的实体类本身并不是有状态的，有状态的是DataContext。但是正是这个有状态的DataContext，造成了实体类也带上了“状态”。对于一般的桌面应用，或者是结合得比较紧密的Web程序，这还不是什么太大的问题。但是如果我们考虑一个分离得比较充分的N层结构，比如说通过WebService提供数据层或者应用层的服务，这就有问题了。例如有一个ModifyCustomer的WebMethod：
publicvoidModifyCustomer(Customercustomer)
{
//
}
由于Customer是反序列化得来的，并不在DataContext的监管中。因此在调用DataContext.SubmitUpdate()的时候，这些对象是无法进行更新操作的。同时DataContext并没有提供一个直接的方法，来进行Update的操作。
这个问题在英文网上还真是有一些讨论，解决的方法就是用DataContext.Attach。
本文共计1398个文字，预计阅读时间需要6分钟。
近期终于得以试用Linq to Sql，刚开始使用，感觉还挺简单。也许是我还不太熟悉，所以也有点‘水土不服’。
（又翻出来一篇一年多以前的半成品，赶紧给补充完整放出来。）
最近终于得以试用Linq to Sql了，刚开始用，感觉还挺不错，因为一切都显得很简单。也许是我还不太熟悉，所以也有不少的困惑。别的先不说，只说一个：“有状态的”实体类。
Linq to Sql 所创建出来的实体类本身并不是有状态的，有状态的是DataContext。但是正是这个有状态的DataContext，造成了实体类也带上了“状态”。对于一般的桌面应用，或者是结合得比较紧密的Web程序，这还不是什么太大的问题。但是如果我们考虑一个分离得比较充分的N层结构，比如说通过WebService提供数据层或者应用层的服务，这就有问题了。例如有一个ModifyCustomer的WebMethod：
publicvoidModifyCustomer(Customercustomer)
{
//
}
由于Customer是反序列化得来的，并不在DataContext的监管中。因此在调用DataContext.SubmitUpdate()的时候，这些对象是无法进行更新操作的。同时DataContext并没有提供一个直接的方法，来进行Update的操作。
这个问题在英文网上还真是有一些讨论，解决的方法就是用DataContext.Attach。