先看一下测试用的数据库：
create table Users (
Id bigint identity(0, 1) primary key,
Account nvarchar(16) unique not null,
Age smallint null,
Gedner nvarchar(4) null default('保密'),
Website varchar(128) null
)
create table Topics(
Id bigint identity(0, 1) primary key,
UserId bigint foreign key references Users(Id) not null,
Title nvarchar(128) not null,
Content ntext not null,
PostTime smalldatetime not null default(getdate())
)
使用VS2008的Linq to SQL Classes工具，生成2个实体类，于是不爽出现了：
1、在IDE视图中表的列名全是小写的，要一一改成大写，如果表多了恐怕会比较辛苦了，论速度还不如自己亲手写
2、看一下Topic这个实体类
private long _Id = default(long);
private long _UserId;
private string _Title;
private string _Content;
private System.DateTime _PostTime;
private EntityRef<User> _user;
在IDE中把列名改成大写后，生成的private属性名也就是首字大写了，也不说是不是符合.NET的命名规范，但是自动生成的一个EntityRef<User>的首字母竟然还是小写的-__这个最终是没找到修改的地方
然后还有这个
public User user
{
get
{
return this._user.Entity;
}
...
}
嗯，连Property也首字小写了...还是不说.NET的命名规范吗...？
3、实体类中含有大量的方法，大概是因为Hibernate用多了，对这种在简单类里面写方法的风格喜欢不起来，一直认为实体类只要负责让用户知道自己是什么就行了，不应该拥有方法......当然应该是我浅薄了~
4、将DataContext及所有的实体类写在一个.cs文件中...不是MS自己说的一个.cs文件应该只含有一个类的定义吗-__
5、实体类没有标记为[Serializable]...这个也没办法有意见，他们喜欢就好
于是总体的感受是：
1、IDE不是太好用
2、命名乱得没法用
3、为实体类提供了事件和一部分方法，使用新的分部方法，可以让用户自己修改
提供的方法有OnLoaded()，OnCreated()及跟踪各个属性变化的方法，实用还是挺实用的
但是!分部方法身为private，竟然首字母大写......
4、总的来说LINQ是强大的，实用的，易用的，比如要从数据库中SELECT一个用户，可以这么写
var testUser = from u in context.Users
where u.Account == user.Account
select u;
也可以这么写
User user = context.Users.Single(u => u.Account == "Rei");
5、更新或插入后别忘了DataContext.SubmitChange();
6、没有专门的UPDATE的方法，因为SELECT后的实体类对象与数据库的元祖是对应的，改变也是同步的，只要SubmitChange()就等同于UPDATE了
7、存储过程就形成一个类，无论你怎么改存储过程的名字，类的名字依旧是你数据库里定义的-___
期待正式版...
刚才试了下，就这么2个实体类，用VS2008自带的代码分析工具分析了一下，对自动生成的.cs文件报了10多个错误，说命名不符合规则
然后根据代码分析器，又看到了一个问题：
对于已经设置为read-only的属性(像自增主键之类的总不能让用户去修改了吧？)，自动生成的代码里竟然同时有set和get，于是代码分析器说，请把set去掉...
不会象你说的那么烂吧
我认为说他烂是错误的，我上面说的都是事实摆在那里
但这并不是一个工具烂的原因，我可以认为是MS赶进度导致的一些疏忽，况且像命名之类的问题，很多都是仁者见仁了
就功能而言，我已经说了，实用、强大、易用，我无法否认这其中所灌注的MS的强大的开发实力
诸如分页等功能LINQ也实现得很好，我们只需要等待正式版对这一些细节问题的改进，不是么
