现在持久性的最佳做法是什么?

时间:2008-12-12 10:19:57

标签: database orm persistence

我来自java背景。

但我希望跨平台的观点来看待持久对象的最佳实践。

我看到它的方式,有3个阵营:

  • ORM阵营
  • 直接查询阵营,例如JDBC / DAO,iBatis
  • LINQ阵营

人们是否仍然手动编码查询(绕过ORM)?为什么,考虑通过JPA,Django,Rails提供的选项。

5 个答案:

答案 0 :(得分:6)

持久性没有一种最佳实践(尽管人们尖叫ORM是最佳实践的人数可能会让你相信其他情况)。唯一的最佳做法是使用最适合您的团队和项目的方法。

我们使用ADO.NET和存储过程进行数据访问(尽管我们确实有一些助手可以快速编写,例如SP类包装器生成器,IDataRecord到对象转换器,以及一些封装常见模式的高阶程序)错误处理)。

这有很多原因,我不会在这里讨论,但足以说它们是适合我们团队的决定,而且我们的团队同意这一点。最重要的是,最重要的是。

答案 1 :(得分:3)

我目前正在阅读.net中的持久对象。因此,我无法提供最佳实践,但也许我的见解可以为您带来一些好处。直到几个月前,我一直使用手写的查询,这是我在ASP.classic时代的坏习惯。

Linq2SQL - 非常轻巧,易于加快速度。我喜欢强类型查询的可能性以及SQL不会立即执行的事实。相反,它会在您的查询准备就绪时执行(应用所有过滤器),因此您可以从数据过滤中拆分数据访问。 Linq2SQL还允许我使用与动态生成的数据对象分开的域对象。我没有在一个更大的项目上尝试过Linq2SQL,但到目前为止看起来很有希望。哦,它只支持MS SQL,这是一种耻辱。

实体框架 - 我玩了一下它并不喜欢它。它似乎想为我做一切,它不适用于存储过程。 EF支持Linq2Entities,它再次允许强类型查询。我认为它仅限于MS SQL,但我可能错了。

SubSonic 3.0(Alpha) - 这是支持Linq的SubSonic的新版本。 SubSonic的酷炫之处在于它基于模板文件(T4模板,用C#编写),您可以轻松修改。因此,如果您希望自动生成的代码看起来不同,您只需更改它:)。到目前为止我只尝试过预览,但今天会看阿尔法。看看SubSonic 3 Alpha。支持MS SQL,但很快就会支持Oracle,MySql等。

到目前为止,我的结论是使用Linq2SQL直到SubSonic准备就绪,然后切换到那个,因为SubSonics模板允许更多的自定义。

答案 2 :(得分:3)

至少有另一个:System Prevalence

据我所知,最适合你的是很大程度上取决于你的情况。我可以看到,对于非常简单的系统,使用直接查询仍然是一个好主意。此外,我已经看到Hibernate无法很好地处理复杂的遗留数据库模式,因此使用ORM可能并不总是有效的选项。如果你有足够的内存来将所有对象都安装到RAM中,那么系统普遍性应该是无法快速的。不知道LINQ,但我认为它也有它的用途。

因此,通常情况下,答案是:了解各种工具,以便您能够使用最适合您特定情况的工具。

答案 3 :(得分:2)

我更喜欢编写自己的SQL,但是当我这样做时,我会应用所有的重构技术和其他“好东西”。

我编写了数据访问层,ORM代码生成器,持久层,UnitOfWork事务管理和LOTS of SQL。我已经在各种形状和大小的系统中完成了这项工作,包括极高性能的数据馈送(每天总计四万个交易的四万个文件,每个交易在两分钟内实时加载)。

最重要的标准是命运,就像控制命运一样。不要让你的ORM工具成为完成工作的障碍,或者是不做正确的借口。最终,所有优秀的SQL都是手写和手动调整的,但是一些不错的工具可以帮助您快速获得良好的初稿。

我对待这个问题与处理UI设计的方式相同。我直接在代码中编写了所有的UI,但是我可能会使用一个可视化设计器来构建我想到的一些基本元素,然后撕掉它生成的代码以启动我自己的代码。

因此,在其任何表现形式中使用ORM工具作为获得一个体面示例的方式 - 看看它如何解决出现的许多问题(密钥生成,关联,导航等)。撕掉它的输出,使它成为你自己的输出,然后重复使用它。

答案 4 :(得分:2)

最佳做法取决于您的情况。

如果您需要具有某种有意义结构的表结构中的数据库对象(每个字段一列,每个实体一行等等),您需要在对象和数据库之间使用某种转换层。这些分为两个阵营:

  • 如果数据库中没有逻辑(只是存储)并且表格很好地映射到对象,那么ORM解决方案可以提供快速可靠的持久性系统。像Toplink和Hibernate这样的Java系统是成熟的技术。

  • 如果持久性中涉及的数据库逻辑,或者您的数据库模式已从对象模型中显着漂移,则由数据访问对象包装的存储过程(具有您喜欢的其他模式)是比ORM更多参与但更灵活。

如果您不需要结构化存储(并且您需要确实确定不这样做,因为将其引入现有数据并不好玩),您可以直接存储序列化对象图在数据库中,绕过了很多复杂性。

豫ICP备18024241号-1