OOP、MVC、(Java)中数据库调用的混淆

对我来说,这一切都是关于关注的分离。每个对象应该有一个,而且只有一个,单一的,责任。所以您的模型在那里表示数据库中的每个表。在您的示例中,将有一个 Monkey POJO 它表示数据库中的一个表猴。假设您在POJO中编写所有的SQL查询,前几个月一切正常,然后您的团队决定他们需要迁移到另一个不完全支持您的SQL语法的数据库供应商,现在怎么办?基本上你已经把你的代码嫁给了一个数据库供应商。此外,处理数据库的代码通常是密集的、长的和重复的。

此外,通过将数据检索推到另一层,您还可以拥有一个可能不是数据库的“数据库”,比如说一些csv文件作为(坏的)示例,但您明白了这一点,您的设计更加灵活。对于开发人员来说,数据库是他/她通过一个公共的、稳定的 interface 不需要知道给定数据库的复杂性。

还有一件事,您通常在数据库中执行四种常见的操作,它们是创建、读取、删除、更新(CRUD),因此,通过将所有数据库逻辑推送到自己的层,您可以在两个地方编写更少的代码:

1. 数据层:因为您有重复的CRUD操作
2. 您的pojo是带有setter/getter的简单普通数据

PS:打破这两个层(应用程序和数据)的最大好处可能是您可以使用以下工具 ORMs 要自动生成所有数据访问层,那么您只需专注于开发应用程序,您可以更轻松地交换、修改、更改数据库。