c# – .NET对象持久性选项

前端之家收集整理的这篇文章主要介绍了c# – .NET对象持久性选项前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我有一个问题,我只是不觉得我找到了一个满意的答案,无论是或者我没有在正确的地方看.

我们的系统最初是使用.NET 1.1构建的(但是所有项目现在都支持3.5),所有实体都使用存储过程和使用标准ExecuteReader,ExecutreNonQuery类型方法的“sqlHelper”持久化到数据库.

所以通常会发生的是我们的实体,例如User和Role,我们将有一个名为UserIO的类,将这些对象持久化到数据库,方法如下:

static UserIO.SaveUser(User user)

单独的IO文件的原因是将IO与实体分开,但是不是仅仅调用更令人满意的:

User.Save()

也许我错了,但是这些“IO”文件散布在整个地方根本就不是正确的.所以我正在考虑看其他选项的持久性,我想知道哪里最好的地方开始.过去我已经使用了数据集,但是有一些特别的表现.我知道LINQ在现在,但我听说,而不是LINQ我应该使用ADO.NET实体框架,但后来有人告诉我,实体框架是不是很正确,我应该等待C#4.0.如果是这种情况,C#4.0就在拐角处,应该继续使用我的“IO”文件方法,并在C#4.0最终发布时从实体框架开始.或者可能有一个更优雅的类结构,我可以使用例如利用部分班?

我应该说,我不是完全替代已经存在的数据访问,我更关心我正在创建的新实体.

对不起,如果这个问题有点笼统,但是我没有太多的人反弹这种想法.

解决方法

我已经成功使用了Entity Framework 3.5.有一些我认为纯粹主义的人,谁认为实体框架违反了一些规则,不应该被使用.

在我看来,唯一重要的规则是你自己的.我建议你开始试验Entity Framework 3.5,因为你现在有了.此外,一旦你可以,你(和其他所有人)需要开始尝试使用.NET 4.0.释放候选人是免费的,所以没有理由至少不知道可用的.

有可能你会发现你像4.0中的EF变化那么多,你想要等待它.同样可能的是,你不会觉得需要等待,并且可以继续从EF获益,因为它在3.5.我有,我很高兴我没有等待.

猜你在找的C#相关文章