7

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

在您的语言中,您喜欢哪个选项,为什么?你什么时候考虑其他人?

4

16 回答 16

4

每次都是ORM,我至少要考虑数据库越好。

于 2008-08-11T19:08:47.250 回答
4

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

它严重依赖依赖注入控制反转原则。数据/持久层只做两件事。它创建、读取、更新和删除数据,并将其映射到域对象格式。

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

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

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

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

</rant>

编辑:哦,是的。这对于 LINQ、SubSonic和其他 ORM 都是如此。

于 2008-08-11T19:24:44.113 回答
3

Ruby on Rails 的ActiveRecord与我目前所见的所有其他东西擦了擦地板。LINQ看起来在某些情况下可能会更好,但 ActiveRecord 非常灵活。

于 2008-08-12T00:42:06.237 回答
2

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

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

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

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

于 2008-08-11T19:07:35.413 回答
2

LINQ 是我从这里开始的方式

于 2008-08-11T19:09:31.900 回答
1

ORM 确实很棒。

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

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

这两者都表明,正确完成的 ORM 非常出色。我对 EJB 的成功和享受较少。

于 2008-08-11T23:35:12.160 回答
1

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

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

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

于 2008-08-11T23:42:06.933 回答
1

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

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

这是使用 java/Oracle。

于 2008-10-09T09:15:34.553 回答
0

在 C# 中,我喜欢使用LINQ to SQL来处理任何新事物,但如果我在 .NET 2.0 上使用 C# ,我真的很喜欢使用.netTiers + CodeSmith Generator来为数据库生成一个快速而肮脏的数据层。

于 2008-08-12T00:32:52.183 回答
0

我非常喜欢Hibernate :)

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

不用说,我迫不及待地想要使用 .NET 3.5 SP1 中的新实体框架(我知道它已经可用,但我有点懒得输入 XML :))

于 2008-08-12T08:05:26.107 回答
0

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

但是(现在戴上 Grumpy Old Man 的帽子)世界上所有的 ORM 都不能替代对 SQL 的良好了解,如果没有这些知识,我真的不希望看到允许访问 RDBMS。

于 2008-08-12T08:55:03.917 回答
0

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

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

于 2008-08-12T11:30:32.120 回答
0

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

于 2008-10-25T05:40:29.383 回答
0

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

于 2008-12-09T06:07:36.250 回答
0

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

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

于 2008-12-09T06:13:37.593 回答
0

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

于 2011-04-09T11:02:38.840 回答