您最喜欢的编程语言与数据库交互的方式是什么？

Question

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

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

Answer 1

ORM每次，至少我必须考虑数据库越好。

Answer 2

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

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

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

业务逻辑层只需知道一件事。商业逻辑。它并不关心数据的来源，也不关心数据层的位置。它知道它应该标记一个刚刚透支的帐户，如何实际执行此操作并不是其工作的一部分。

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

在一天结束的时候，我觉得我的代码库非常清晰，层次分明。通过一些严格的接口和良好的基类，大多数编码只是告诉软件在X发生时要做什么。应该是怎么回事。

</rant>

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

Answer 3

Ruby on Rails'ActiveRecord用我迄今为止见过的所有内容擦拭地板。 LINQ看起来在某些情况下可能会更好，但ActiveRecord非常灵活。

Answer 4

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

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

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

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

Answer 5

LINQ是我从这里开始的方式

Answer 6

ORM确实太棒了。

我在python中工作时使用SQL Alchemy - 它几乎适用于我遇到的每个DBMS。

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

这两个都表明ORM做得很好。我对EJB的成功和享受较少。

Answer 7

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

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

自Visual Studio 2005以来，这已经出现，并且通过我的新网络应用程序彻底减少了我的“结构”时间，我可以更专注于业务和表示逻辑。

Answer 8

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

• 在阅读要显示的信息页面并供用户更新时，我们使用Hibernate
• 在处理一批更新或总结大部分数据已经在数据库中的位置时（例如，一天结束处理），我们使用PL / SQL（并尝试成套思考）
• 当用户执行搜索或运行摘要报告时，我们使用ibatis sqlmaps构建一些SQL并仅返回我们感兴趣的字段（不是每一列，当然也不是任何不必要的子行，urggh）
• 任何真正需要快速运行的东西，我们会使用最好的方法

这是使用java / Oracle。

Answer 9

在C＃中，我喜欢LINQ to SQL以获取任何新内容，但我真的很喜欢使用.netTiers + CodeSmith Generator来获取数据库快速而脏的数据层，如果我正在使用C＃在.NET 2.0上。

Answer 10

我很喜欢Hibernate：）

我知道它有一个学习曲线，但是一旦你掌握了它，就会很好。

毋庸置疑，我迫不及待地想要开始使用.NET 3.5 SP1中的新Entity Framework（我知道它已经可用，但我有点懒于输入XML :)）

Answer 11

ActiveRecord，这是Fowler Patterns of Enterprise Architecture中首先记录的模式（我认为）。我相信它是用Ruby以外的语言实现的，尽管它在Rails中作为核心技术而闻名。无论如何，它是数据库的简洁抽象，尽管我必须承认我发现它有点笨拙并且在find_by_sql区域。但那可能只是我。

但是（现在戴上Grumpy Old Man帽子）世界上所有的ORM都无法替代对SQL的良好了解，没有它我真的不喜欢看到允许访问RDBMS。

Answer 12

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

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

Answer 13

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

Answer 14

最喜欢的方法是将Smalltalk与GemStone对象存储库一起使用。为什么？没有ORM问题需要处理。如果被雇主强迫或威胁，我只会考虑别的事情。

Answer 15

我最喜欢的方法是拥有一个对象抽象层。理想情况下，这是仅适用于SQL的地方。但实际上，对象有时也需要做SQL-y的事情。但没有任何东西在外面。

到目前为止，我自己写过这样的图层，因为可用的内容太笨拙，太慢或太大。

Answer 16

我使用普通的JDBC，因为我正在开发一个数据驱动的应用程序，我的数据库模型非常复杂。数据库中描述了所有内容，甚至是其他表的结构。除此之外，我还使用了很多存储过程。因此，ORM不适合我。