java - 在我的例子中是否值得创建一个数据访问层？

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭 7 年前。

Improve this question

场景:

假设我必须建立一个网站来与旧数据库交互。短期内不会更换供应商。性能是需要的，对于大多数表，我们只会处理列的子集，这些列的子集可能因查询而异，因此我们通常不会处理整个“实体”。

问题:

除了服务和表示层之外，是否值得创建一个专用的数据访问层？或者从服务层直接与 JDBC 交互以避免多重映射(本例中为 2)会更正确？

摘要:

DAL <---> BL <---> 演示文稿VSBL/DAL 混合 <---> 演示

Answer 1

是的。

始终将 JDBC 隐藏到专用数据访问层中是一个好主意。您也可以将其用作 ACL(请参阅域驱动设计 - 反腐败层)，它用作映射器，以您想要操作的方式表示遗留数据。

除了极少数琐碎的 CRUD 数据库之外，通常数据库模型(也称为存储模型)不是域模型的 1:1 表示(在应用程序中以对象表示数据的方式)。因此，“我只需要几列”问题在任何项目中都是完全有效的。

15 年前，ORM 映射器(例如 Hibernate、Linq)开始提供一种向开发人员隐藏这种“复杂性”的方法，给人一种您不需要考虑存储模型的错误印象，而存储模型可以从领域模型中推断出来。然而，这个解决方案对性能造成了极其严重的影响——数据库架构师很容易理解，但对大多数 Java 程序员来说很难解释:)

5年前，领域驱动设计方法开始采取这种不那么紧张的方式，明确指出“相同”的数据可以在不同的子系统(例如在数据库中)中进行不同的建模，并且这一切都可以，因为我们可以将数据转换为我们的需要，即使数据来自 XML 或 JSON 或者具有奇怪的列名或其他邪恶的数据。这种方法称为反腐败层 (ACL) - 尤其是当您在表示相同数据的不同系统之间“转换”时，代码中的专用位置。

在你的例子中，你可以做更多的事情，而不是使用这个数据访问层作为一个无脑的 DAO，它只是 1:1 将所有表列读取到一个类中:

• 创建一个存储库(因此是一个处理数据操作的单独类)
• 存储库接受并检索您的格式的数据(仅限正确的列等)
• 使用 select 语句来选择您需要的数据，连接到其他旧表并使用 case/decode 语句来获取您需要的格式的数据(因此将存储数据模型转换为域数据模型)
• 更新或插入某些内容时，在此 ACL 代码中，您可以根据您的存储数据模型自由插入/更新多个表(因此将您的域数据模型转换为存储数据模型)