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

Posted 2023-02-16

技术标签:

【中文标题】你最喜欢用你的编程语言与数据库交互的方式是啥？ [关闭]【英文标题】：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)、存储过程等。

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

【问题讨论】：

【参考方案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 操作。但在对象之外什么都没有。

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

【讨论】：