你最喜欢用你的编程语言与数据库交互的方式是什么？ [关闭]答案

【问题标题】：What's your favourite way of interacting with databases from your programming language? [closed]你最喜欢用你的编程语言与数据库交互的方式是什么？ [关闭]
【发布时间】：2010-09-05 16:54:12
【问题描述】：

有很多方法可以连接数据库层并与之交互。例如，在 Java 中，常见用法是 JDBC 调用原始 SQL、对象关系映射器、JDBCTemplate (Spring)、存储过程等。

在您的语言中，您更喜欢哪个选项，为什么？你什么时候会考虑其他人？

【问题讨论】：

标签： database design-patterns

【解决方案1】：

我更喜欢构建业务对象模型层（对象和对象集合）。

我将与数据库交互的能力构建到每个对象/集合中（对于 SQL Server，我使用System.Data.SqlClient）。我已经将这种模式用于 SQL Server、MySQL 和 Oracle。

然后我与应用程序代码中的对象进行交互。

通过将我的数据库抽象为对象，无论后端数据库如何，我的应用程序代码都是一致的。

【讨论】：

【解决方案2】：

ORM 每次都是，我对数据库的考虑越少越好。

【讨论】：

如果您想从数据库中读取 10000 行并将总数存储在某处怎么办？既然可以，为什么要在网络上拖动所有内容：插入总计.. 从详细信息中选择？
使用 ORM，您无需读取 10000 行即可获得总数。例如，在 LinqToSql 中，可以使用 Sum 方法对属性求和，然后将其转换为适当的 SQL，让 sql server 计算总和而不返回所有行。
@Ole：LinqToSql（它只支持SQL Server，可能已经不赞成Entity Framework）还是一个黑盒子，为什么不自己写SQL呢？如果将汇总逻辑放在存储过程中，则无需授予应用程序对表的原始访问权限。

【解决方案3】：

LINQ 是我从这里开始的路

【讨论】：

【解决方案4】：

我真的很喜欢 3 + 1 层的做事方式。一层用于 UI，一层用于业务逻辑和持久化数据。你说的最后一个？域对象和接口。这使得加载任何一两个主层以及域“层”成为可能，并且代码应该可以工作。

它严重依赖dependency injection 和Inversion of Control 原则。数据/持久层只做两件事。它创建、读取、更新和删除数据，并将其映射到域对象格式。

UI 层的作用正好相反。它以用户可以关联的方式显示和接收数据，并将输出/输入映射到域对象格式和来自域对象格式的映射。

业务逻辑层只需要知道一件事。商业逻辑。它不关心数据来自哪里，也不关心数据层将数据放在哪里。它知道它应该标记一个刚刚透支的帐户，实际上如何做到这一点并不是它工作的一部分。

领域对象本身没有任何逻辑，它们只是用于在层之间传递数据的容器。这意味着您可以加载域对象和接口，而无需考虑依赖关系。

在一天结束的时候，我觉得我有一个非常清晰的代码库和清晰的分层。并且通过一些严格的接口和良好的基类，大多数编码只是告诉软件当 X 发生时该做什么。就是应该的样子。

</rant>

编辑：哦，是的。 LINQ、SubSonic 和其他 ORM 都是如此。

【讨论】：

【解决方案5】：

ORM 确实很棒。

我在使用 python 时使用 SQL Alchemy - 它几乎适用于我遇到的所有 DBMS。

对于 MacOS X 上的轻量级数据驱动应用程序，我使用 Core Data，它具有可通过 Xcode 访问的出色数据建模工具。

这两者都表明正确的 ORM 非常出色。我在 EJB 方面的成功和乐趣都比较少。

【讨论】：

【解决方案6】：

我还没有进入 LINQ 世界，但我真的很喜欢 Visual Studio 通过 XSD 数据集完成的 DataTable/TableAdapter 类。在创建我的数据库模式后通过几次拖动和单击，我现在有一个强类型的 DataSet/DataTable 对象，并且我有适配器方法，这些方法对我的所有 CRUD 语句的存储过程使用参数化查询。它甚至会为一些不直接绑定到表的过程创建查询表适配器。

哦，如果您还没有创建存储过程并且只有表，那么向导将为您创建过程或即席 SQL 语句。

这从 Visual Studio 2005 开始就已经推出，大大减少了我使用新 Web 应用程序的“结构”时间，我可以更多地专注于业务和演示逻辑。

【讨论】：

【解决方案7】：

在 C# 中，我喜欢 LINQ to SQL 来获得任何新的东西，但如果我在 .NET 2.0 上使用 C#，我真的很喜欢使用 .netTiers + CodeSmith Generator 来获得一个快速而肮脏的数据库数据层。

【讨论】：

【解决方案8】：

Ruby on Rails 的ActiveRecord 用我迄今为止看到的所有其他东西擦拭地板。 LINQ 看起来在某些情况下可能会更好，但 ActiveRecord 非常灵活。

【讨论】：

【解决方案9】：

我非常喜欢Hibernate :)

我知道它有一个学习曲线，但是一旦你掌握了它，它就相当不错了。

不用说，我已经迫不及待想要获得 .NET 3.5 SP1 中的新 Entity Framework（我知道它已经可用，但我有点懒得输入 XML :)）

【讨论】：

【解决方案10】：

ActiveRecord，这是 Fowler 的 Patterns of Enterprise Architecture 中首先记录的（我认为）模式。我相信它是用 Ruby 以外的语言实现的，尽管它是众所周知的 Rails 的核心技术。不管怎样，它是一个简洁的数据库抽象，尽管我不得不承认我发现它有点笨拙并且位于 find_by_sql 区域。但这可能只是我。

但是（现在戴上 Grumpy Old Man 的帽子）世界上所有的 ORM 都无法替代良好的 SQL 知识，如果没有这些知识，我真的不希望看到允许访问 RDBMS。

【讨论】：

【解决方案11】：

我们目前正在使用ODAC 与 Oracle 数据库通信并使用大量 Oracle 包 (PL/SQL)。 n 层系统是通过 RemObjects 完成的，这意味着我们的客户端中没有任何 SQL，只需要发送 HTTP 请求的能力，因此没有安装开销。

所有这些都是使用 Borland Delphi 完成的，并且已经在生产环境中工作了 2 年。

【讨论】：

【解决方案12】：

我们使用混合方法，具体取决于适合应用程序中特定情况的方法：

在读取需要显示的信息页面以及供用户更新时，我们使用 Hibernate
在处理一批更新或总结大部分数据已在数据库中的位置时（例如，日终处理），我们使用 PL/SQL（并尝试在集合中思考）
当用户执行搜索或运行摘要报告时，我们使用 ibatis sqlmaps 构建一些 SQL 并仅带回我们感兴趣的字段（不是每一列，当然也不是任何不必要的子行，呃）李>
真正需要快速运行的任何方法，我们都会使用最有效的方法

这是使用 java/Oracle 的。

【讨论】：

【解决方案13】：

我们通过 Oracle.OleDBProvider 使用 Delphi 和 Oracle 数据访问组件 (ODAC) 和 ADO。

【讨论】：

【解决方案14】：

可能最喜欢的方式是将 Smalltalk 与 GemStone 对象存储库一起使用。为什么？无需处理 ORM 问题。如果我的雇主强迫或威胁我，我只会考虑其他事情。

【讨论】：

【解决方案15】：

我最喜欢的方法是拥有一个对象抽象层。理想情况下，这是唯一可以使用 SQL 的地方。但在实践中，对象有时也需要执行 SQL-y 操作。但在对象之外什么都没有。

到目前为止，我自己编写了这样的层，因为可用的层太笨拙、太慢或太大。

【讨论】：

【解决方案16】：

我使用普通的 JDBC，因为我正在开发一个数据驱动的应用程序并且我的数据库模型非常复杂。一切都在数据库中描述，甚至是其他表的结构。除此之外，我还经常使用存储过程。因此 ORM 不是我的选择。

【讨论】：