我有一个关于如何在使用 mysql 等 RDBMS 时使用面向对象方法的问题。我正在开发一个跟踪计费的小型应用程序。它是用 java 构建的，我使用 MySQL 数据库来存储数据。我的应用程序有一个客户和一个产品类。现在通常，如果我使用数组或不同的数据容器处理持久数据存储，我将对客户类和产品类进行更新、删除等操作。但是，我发现自己使用的静态方法比以往任何时候都多。因为我没有客户数组，例如，我只有一个包含客户信息的数据库在它的主要ID上。
我想问大家的是，在使用 RDBMS 的时候，你们是如何采用面向对象的方式呢？
使用 OO 原则设计您的 Java 类。
使用 SQL 和规范化原则设计您的数据库。
然后，全速挑战对象/关系映射！:-)
像 Hibernate 和 Ibatis 这样的技术是专门为解决这个问题而设计的，这是一个有据可查的问题。像 Spring 这样的附加技术可以使它们的使用变得非常容易和愉快。
将您的持久性抽象到 DAO（数据访问对象）层，例如，如果您有很多像 Vehicle 和 Animal 这样的类，那么您将拥有像 VehicleDao 和 AnimalDao 这样的 DAO，以将它们与 DB 的对话方式与它们在本质上所做的事情区分开来你的系统。
FWIW，我提倡这样做：在应用程序端进行良好的应用程序设计，在数据端进行良好的数据库设计。完成此操作后，总有一种方法可以在将类数据持久化到数据库和从数据库中检索类数据时映射两者，这比 IMO 妥协一个单独的层来“帮助”另一个要好得多。
您的数据库代表您的业务对象 - 完全规范化等。
您的对象模型表示您需要如何处理代码中的数据。它们通常不相同，例如，您有一个客户表以一对多的方式链接到地址表，但在代码中您使用的对象包含这两种类型的信息。
您的数据访问对象 (DAO) 处理业务对象（即读/写）。您的服务层完成工作，必要时将 DAO 的输出组合到您的对象中。您的服务层也将根据需要处理事务。
从您的服务层抽象您的数据访问将使维护代码、更新数据库模式和促进测试变得更加容易。
处理数据库和 oo-code 始终是一个热门话题。有些人可能会说“只是不要”。
我不同意这些，但是当我不得不这样做时，我已经看到了很多问题。我绝对不同意其他一些立即推荐像 Hibernate 这样的 OR-Mapper 的人。在许多情况下，您在开发过程中并没有真正获得任何好处，并且在运行时会遇到很多问题（性能、错误诊断）。
与往常一样，这一切都取决于您在应用程序中所做的事情。你说，你没有客户对象。为什么是这样？例如，如果您只是在 gui 内的一个表中显示所有客户，并且用户可以通过右键单击或其他方式删除其中一个，最好的方法是通过 JDBC 读取 DB 数据，将其放入您的 JTable 并拥有一个再次使用 JDBC 的静态删除方法。
但是，如果您真的在应用程序内部与客户打交道，那么建立客户对象将很有用，然后您需要OR-Mapping。但是你不需要一个框架。在大多数情况下，手写的 sql/JDBC 都做得很好。
从我的角度来看，OR-Mapper-Frameworks 在性能不感兴趣的应用程序中可能是一件好事，并且在大多数其他情况下，您没有心情考虑所有数据库的东西（即原型设计）我会去带有用于读取和存储的手写代码。
领域模型是一个很好的方法。将您的业务逻辑分离到不直接依赖数据库的层中。使用SOLID原则并查看领域驱动设计。这样，您将拥有可读的 OO 代码，这些代码是隔离的并且可以轻松测试。像“存储库”这样的模式将帮助您在处理关系数据库的现实时专注于业务需求。本质上，您定义和接口如下：
List<Customer> customers = Customers.WithOutstandingOrders(DateRange range)
然后在数据访问层（在你的域之外）实现这个接口。最简单的方法是像 Hibernate 一样使用 ORM。数据库在这个架构中的作用更像是一个“位桶”。换句话说，大多数逻辑都存在于 OO 代码中，而数据库只是防止数据异常并加快处理速度（使用规范化、引用完整性和索引）。
使用 DTO（数据传输对象）（在您的情况下是表示数据库中对象的类）遵守单一职责原则。这是一种基于 OOP 原则（更具体地说是封装过程）的设计模式。这可确保您的每个类只完成一个目的。如果您将业务逻辑保存在 SQL 字符串中，则很难维护并违反 DRY “不要重复自己”的原则。根据我的经验，ORM 加快了系统设计的过程。试试 NHibernate。http://geekswithblogs.net/pariam/archive/2006/07/26/86352.aspx
如果您希望此应用程序不断增长（这可能是 99% 的应用程序），请创建对象。即使删除是单个 SQL 调用，您也可能需要添加逻辑（删除子表中的行、存储审计数据、移至逻辑删除而不是硬删除等）