问题标签 [orm]

我有一个我目前正在处理的项目，但它目前只支持 .net 框架 2.0。我喜欢 linq，但由于框架版本的原因，我无法使用它。我想要的不是事物的 ORM 方面，而是 Linq 的“可查询性”（甚至是一个词吗？）。

到目前为止，最接近的是llblgen，但如果有更轻的重量可以为我做查询，那就更好了。

我还查看了NHibernate，它看起来可以接近我想要的，但它的学习曲线非常陡峭，并且映射文件不会让我过于兴奋。

如果有人知道可以为我提供与 Linq 类似的查询界面（或者更好的是，如何让 Linq 在 .net 2.0 框架上工作），我真的很想听听。

我继承了一个旧的硬壳PHP application，我想将它重构为更好处理的东西，但要循序渐进。在 perl 的 CPAN 中，围绕 Class::DBI 有一系列类，它们允许您使用数据库行作为代码中对象的基础，并根据需要生成库accessor methods等，还允许您添加其他方法。

有谁知道这样的PHP？尤其是不需要大规模采用“框架”的东西……如果它也可以在 PHP4 中工作，那么可以加分，但老实说，我很想有另一个理由放弃它。:-)

在 wiki 或论坛或博客软件等 Web 应用程序中，将数据存储在关系数据库中通常很有用。由于许多托管公司在其托管计划中提供单个数据库（额外的数据库需要额外付费），因此当您的数据库对象（表、视图、约束和存储过程）具有公共前缀时，这对您的用户非常有用。意识到数据库稀缺性的应用程序通常具有硬编码的表前缀。然而，我想要更多。具体来说，我希望有一个用户可以指定的表前缀——比如在 web.config 文件中（当然，使用适当的默认值）。

因为我讨厌手动编写CRUD操作，所以我更喜欢通过有能力的 OR/M 工作，并且使用（并喜欢）LINQ to SQL、Subsonic 和 ADO.Net。但是，在将表前缀放入用户的 web.config 文件中时，我在一个新项目中遇到了一些麻烦。是否有任何基于 .Net 的 OR/M 产品可以优雅地处理这种情况？

到目前为止，我能想到的最好的方法是使用带有外部映射文件的 LINQ to SQL，我必须根据一个尚未假设的 web.config 设置以某种方式更新该文件。

有人有更好的解决方案吗？我试图在实体框架中实现它，但很快就变成了一团糟。（由于我对 EF 不熟悉？可能。） SubSonic 怎么样？除了在代码生成时，它是否可以选择应用表前缀？

我们在这里使用自己的 ORM，并为我们所有的数据库表提供强类型包装器。我们还允许执行弱类型的 ad-hoc SQL，但这些查询仍然通过同一个类从数据读取器中获取值。

在调整该类以使用 Oracle 时，我们遇到了一个有趣的问题。使用 DBNull.Value 还是 null 更好？使用 DBNull.Value 有什么好处吗？使用 null 似乎更“正确”，因为我们已经将自己与 DB 世界分开了，但是有一些影响（例如，当值为 null 时，你不能盲目地ToString()）所以它绝对是我们需要意识到的关于的决定。

我是第一次使用 LINQ，当我在 SQL 中有一种货币类型时，我想让映射工作，但我的域对象属性是 double 类型。如何在 XML 文件或代码中表达这一点，以便映射不会引发通常的“无效转换”异常？

I've seen projects where the classes in the DB layer have just static functions in them and other projects where those classes need to be instantiated to get access to the member functions.

Which is "better" and why?

因此，ADO.NET 实体框架受到了一些负面报道（以博客条目和请愿书的形式），但我不想急于做出判断。我的实验时间有限，但我想知道是否有人使用它并获得更多经验反馈？

最后，关于使用已经存在很长时间并且可能比 ADO.NET Entity Framework 更成熟的 NHibernate 有什么想法。

我真的需要看到一些关于当前接受的企业应用程序设计范式优点的诚实、深思熟虑的辩论。

我不相信实体对象应该存在。

我所说的实体对象是指我们倾向于为我们的应用程序构建的典型事物，例如“Person”、“Account”、“Order”等。

我目前的设计理念是这样的：

• 所有数据库访问都必须通过存储过程完成。
• 每当您需要数据时，调用存储过程并遍历 SqlDataReader 或 DataTable 中的行

（注意：我还使用 Java EE 构建了企业应用程序，Java 人员请用等价物代替我的 .NET 示例）

我不反对OO。我为不同的目的编写了很多类，而不是实体。我承认我写的大部分类都是静态辅助类。

我不是在制造玩具。我说的是跨多台机器部署的大型、大容量事务应用程序。Web 应用程序、Windows 服务、Web 服务、b2b 交互，应有尽有。

我用过 OR 映射器。我已经写了几篇了。我使用了 Java EE 堆栈、CSLA 和其他一些等价物。我不仅使用过它们，而且还在生产环境中积极开发和维护这些应用程序。

我得出了久经考验的结论，实体对象正在阻碍我们，我们的生活将如此得多。

考虑这个简单的例子：你接到一个关于你的应用程序中某个页面不能正常工作的支持电话，也许其中一个字段没有像它应该的那样被持久化。使用我的模型，分配来查找问题的开发人员恰好打开了 3 个文件。一个 ASPX、一个 ASPX.CS 和一个带有存储过程的 SQL 文件。该问题可能是存储过程调用中缺少参数，需要几分钟才能解决。但是对于任何实体模型，您总是会启动调试器，开始单步执行代码，最终您可能会在 Visual Studio 中打开 15-20 个文件。当你走到栈底时，你已经忘记了从哪里开始。我们一次只能在脑海中保留这么多东西。软件非常复杂，无需添加任何不必要的层。

开发复杂性和故障排除只是我抱怨的一方面。

现在让我们谈谈可扩展性。

开发人员是否意识到，每次编写或修改与数据库交互的任何代码时，他们都需要彻底分析对数据库的确切影响？不仅仅是开发副本，我的意思是模拟生产，所以您可以看到您现在为您的对象需要的附加列刚刚使当前查询计划无效，并且在 1 秒内运行的报告现在需要 2 分钟，只是因为您在选择列表中添加了一列？事实证明，您现在需要的索引太大以至于 DBA 将不得不修改文件的物理布局？

如果你让人们通过抽象离物理数据存储太远，他们将对需要扩展的应用程序造成严重破坏。

我不是狂热者。如果我错了，我可以确信，也许我错了，因为对 Linq to Sql、ADO.NET EF、Hibernate、Java EE 等的推动力如此之大。请仔细考虑你的回答，如果我遗漏了什么我真的很想知道它是什么，以及为什么我应该改变我的想法。

[编辑]

看起来这个问题突然又活跃起来了，所以现在我们有了新的评论功能，我已经直接评论了几个答案。感谢您的回复，我认为这是一个健康的讨论。

我可能应该更清楚我在谈论企业应用程序。我真的无法评论，比如说，在某人的桌面上运行的游戏或移动应用程序。

为了回应几个类似的答案，我必须把一件事放在首位：正交性和关注点分离经常被引用为使用实体/ORM 的理由。对我来说，存储过程是我能想到的关注点分离的最好例子。如果您不允许通过存储过程以外的所有其他方式访问数据库，那么理论上您可以重新设计整个数据模型并且不会破坏任何代码，只要您维护存储过程的输入和输出即可。它们是合同编程的完美示例（只要您避免“选择 *”并记录结果集）。

问一个在这个行业工作了很长时间并使用过长期应用程序的人：在数据库存在的情况下，有多少应用程序和 UI 层来了又去？当有 4 或 5 个不同的持久层生成 SQL 以获取数据时，调整和重构数据库有多难？你什么都改变不了！ORM 或任何生成 SQL 的代码都将您的数据库锁定在石头上。

我有两个模型：消息和附件。每个附件都使用附件模型上的 ForeignKey 附加到特定消息。两个模型都有一个名为 updated 的 auto_now DateTimeField。我正在尝试这样做，以便在保存任何附件时，它还将关联消息上的更新字段设置为现在。这是我的代码：

这行得通吗？如果你能向我解释一下，为什么？如果没有，我将如何做到这一点？

我正在玩弄将 ORM 逐步引入我支持的应用程序的想法。该应用程序不是很结构化，没有单元测试。所以任何改变都是有风险的。我显然担心我有足够的理由改变。这个想法是用于数据访问的样板代码将更少，从而提高生产力。

这与你的经历相符吗？
分阶段实施它是否可能，甚至是一个好主意？
ORM 的缺点是什么？