我来自java背景。
但我希望跨平台的观点来看待持久对象的最佳实践。
我看到它的方式，有3个阵营：
人们是否仍然手动编码查询（绕过ORM）？为什么，考虑通过JPA，Django，Rails提供的选项。
答案 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)
最佳做法取决于您的情况。
如果您需要具有某种有意义结构的表结构中的数据库对象（每个字段一列，每个实体一行等等），您需要在对象和数据库之间使用某种转换层。这些分为两个阵营：
如果数据库中没有逻辑（只是存储）并且表格很好地映射到对象，那么ORM解决方案可以提供快速可靠的持久性系统。像Toplink和Hibernate这样的Java系统是成熟的技术。
如果是持久性中涉及的数据库逻辑，或者您的数据库模式已从对象模型中显着漂移，则由数据访问对象包装的存储过程（具有您喜欢的其他模式）是比ORM更多参与但更灵活。
如果您不需要结构化存储（并且您需要确实确定不这样做，因为将其引入现有数据并不好玩），您可以直接存储序列化对象图在数据库中，绕过了很多复杂性。
答案 4 :(得分：2)
我更喜欢编写自己的SQL，但是当我这样做时，我会应用所有的重构技术和其他“好东西”。
我编写了数据访问层，ORM代码生成器，持久层，UnitOfWork事务管理和LOTS of SQL。我已经在各种形状和大小的系统中完成了这项工作，包括极高性能的数据馈送（每天总计四万个交易的四万个文件，每个交易在两分钟内实时加载）。
最重要的标准是命运，就像控制命运一样。不要让你的ORM工具成为完成工作的障碍，或者是不做正确的借口。最终，所有优秀的SQL都是手写和手动调整的，但是一些不错的工具可以帮助您快速获得良好的初稿。
我对待这个问题与处理UI设计的方式相同。我直接在代码中编写了所有的UI，但是我可能会使用一个可视化设计器来构建我想到的一些基本元素，然后撕掉它生成的代码以启动我自己的代码。
因此，在其任何表现形式中使用ORM工具作为获得一个体面示例的方式 - 看看它如何解决出现的许多问题（密钥生成，关联，导航等）。撕掉它的输出，使它成为你自己的输出，然后重复使用它。