在我的情况下值得创建一个数据访问层吗？

Question

该场景：

假设我不得不建立一个网站来与遗留数据库交互。供应商不会很快被替换。性能是必要的，对于大多数表，我们只能处理可能因查询而异的列的子集，所以我们大多不会与整个“实体”一起工作。

问题：

是从服务和介绍一个值得创建一个专用的数据访问层分开？或者，从服务层直接与JDBC进行交互以避免多重映射（本例中为2）会更加正确？

总结：

DAL < ---> BL < --->演示 VS BL/DAL混合< --->演示

Answer 1

是。

在任何时候，将JDBC隐藏到专用数据访问层是一个好主意。您也可以将其用作ACL（请参阅域驱动设计 - 反腐层），它可用作映射器，以您希望操作的方式表示遗留数据。

除了非常少见的CRUD数据库之外，通常数据库模型（又名存储模型）不是域模型的1：1表示（您在应用程序中用对象表示数据的方式）。因此，“我只需要几列”问题在任何项目中都是完全有效的。

15年前，ORM映射器（例如Hibernate，Linq）开始提供一种方法来隐藏开发人员的这种“复杂性”，给人错误的印象，认为您不需要考虑存储模型和存储模型可以从领域模型推断出来。然而，这种解决方案的性能非常严重 - DB架构师很容易理解，并且很难向大多数Java程序员解释:)

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

在你的情况，而不是使用这个数据访问层作为一个没有头脑的DAO刚刚1：1读取所有表列成一类，你可以做多一点：

• 创建库（所以一个处理数据操作的独立类）
• respository接受和检索格式的数据（只有右列等））
• 使用select语句选择需要的数据，加入其他旧表并使用大小写/解码语句获取所需格式的数据（因此将存储数据模型转换为您的域数据模型）
• 更新或插入的东西，在这个ACL代码时，你可以自由地插入/更新多个表的具体取决于您的存储数据模型（所以转换域数据模型存储数据模型）