有许多方法可以连接数据库层并与之交互。例如,在 Java 中,常见的用法是原始 SQL 的JDBC调用、对象关系映射器、JDBCTemplate ( Spring )、存储过程等。
在您的语言中,您喜欢哪个选项,为什么?你什么时候考虑其他人?
每次都是ORM,我至少要考虑数据库越好。
我真的很喜欢 3 + 1 层的做事方式。一层用于 UI,一层用于业务逻辑和持久化数据。你说的最后一个?域对象和接口。这使得加载任何一两个主层以及域“层”成为可能,并且代码应该可以工作。
它严重依赖依赖注入和控制反转原则。数据/持久层只做两件事。它创建、读取、更新和删除数据,并将其映射到域对象格式。
UI 层的作用正好相反。它以用户可以关联的方式显示和接收数据,并将输出/输入映射到域对象格式和从域对象格式映射。
业务逻辑层只需要知道一件事。商业逻辑。它不关心数据来自哪里,也不关心数据层将数据放在哪里。它知道它应该标记一个刚刚透支的帐户,实际上如何做到这一点并不是它工作的一部分。
域对象本身没有任何逻辑,它们只是用于在层之间传递数据的容器。这意味着您可以加载域对象和接口,而无需考虑依赖关系。
归根结底,我觉得我有一个非常清晰的代码库和清晰的分层。并且通过一些严格的接口和良好的基类,大多数编码只是告诉软件当 X 发生时该做什么。它应该是怎样的。
</rant>
编辑:哦,是的。这对于 LINQ、SubSonic和其他 ORM 都是如此。
Ruby on Rails 的ActiveRecord与我目前所见的所有其他东西擦了擦地板。LINQ看起来在某些情况下可能会更好,但 ActiveRecord 非常灵活。
我更喜欢构建业务对象模型层(对象和对象集合)。
我将与数据库交互的能力构建到每个对象/集合中(对于 SQL Server,我使用System.Data.SqlClient)。我已经将这种模式用于 SQL Server、MySQL 和 Oracle。
然后我与我的应用程序代码中的对象进行交互。
通过将我的数据库抽象为对象,无论后端数据库如何,我的应用程序代码都是一致的。
LINQ 是我从这里开始的方式
ORM 确实很棒。
我在 python 中工作时使用 SQL Alchemy - 它几乎适用于我遇到的每个 DBMS。
对于 MacOS X 上的轻量级数据驱动应用程序,我使用 Core Data,它具有可通过 Xcode 访问的出色数据建模工具。
这两者都表明,正确完成的 ORM 非常出色。我对 EJB 的成功和享受较少。
我还没有进入 LINQ 世界,但我真的很喜欢 Visual Studio 通过 XSD 数据集完成的 DataTable/TableAdapter 类。在创建我的数据库模式后通过几次拖动和单击,我现在有一个强类型的 DataSet/DataTable 对象,并且我有适配器方法,这些方法对我的所有 CRUD 语句的存储过程使用参数化查询。它甚至会为一些不直接绑定到表的过程创建查询表适配器。
哦,如果您还没有创建存储过程并且只有表,那么向导将为您创建过程或即席 SQL 语句。
这自 Visual Studio 2005 以来就已经推出,并且大大减少了我使用新 Web 应用程序的“结构”时间,我可以更多地专注于业务和演示逻辑。
我们使用混合方法,具体取决于适合应用程序中特定情况的方法:
这是使用 java/Oracle。
在 C# 中,我喜欢使用LINQ to SQL来处理任何新事物,但如果我在 .NET 2.0 上使用 C# ,我真的很喜欢使用.netTiers + CodeSmith Generator来为数据库生成一个快速而肮脏的数据层。
ActiveRecord,这是 Fowler's Patterns of Enterprise Architecture中首先记录的一种模式(我认为) 。我相信它是用 Ruby 以外的语言实现的,尽管它是众所周知的 Rails 的核心技术。不管怎样,它是一个简洁的数据库抽象,尽管我不得不承认我发现它有点笨拙并且位于 find_by_sql 区域。但这可能只是我。
但是(现在戴上 Grumpy Old Man 的帽子)世界上所有的 ORM 都不能替代对 SQL 的良好了解,如果没有这些知识,我真的不希望看到允许访问 RDBMS。
我们通过 Oracle.OleDBProvider 使用 Delphi 和 Oracle 数据访问组件 (ODAC) 和 ADO。
可能最喜欢的方法是将 Smalltalk 与 GemStone 对象存储库一起使用。为什么?无需处理 ORM 问题。如果我的雇主强迫或威胁我,我只会考虑其他事情。
我最喜欢的方法是拥有一个对象抽象层。理想情况下,这是唯一可以使用 SQL 的地方。但在实践中,对象有时也需要执行 SQL-y 操作。但在对象之外什么都没有。
到目前为止,我自己编写了这样的层,因为可用的层太笨拙、太慢或太大。
我使用普通的 JDBC,因为我正在开发一个数据驱动的应用程序并且我的数据库模型非常复杂。一切都在数据库中描述,甚至是其他表的结构。除此之外,我还经常使用存储过程。因此 ORM 不是我的选择。