【发布时间】:2023-03-10 10:40:01
【问题描述】:
当您说“精简数据访问层”时,这是否主要意味着您是在谈论手动编写 SQL,而不是依靠 ORM 工具为您生成它?
【问题讨论】:
标签: terminology data-access-layer
当您说“精简数据访问层”时,这是否主要意味着您是在谈论手动编写 SQL,而不是依靠 ORM 工具为您生成它?
【问题讨论】:
标签: terminology data-access-layer
这可能取决于谁说的,但对我来说,薄的数据访问层意味着该层几乎没有额外的逻辑(即数据存储抽象),可能不支持针对多个 RDBMS,没有层-特定缓存,无高级错误处理(重试、故障转移)等。
由于 ORM 工具倾向于提供其中的许多功能,使用 ORM 的解决方案可能不会被视为“瘦”。许多本土数据访问层如果提供上述功能,也不会被视为“瘦”。
【讨论】:
取决于我们如何定义“瘦”这个词。这是我听到的最被滥用的术语之一,只有“轻量级”才能与之匹敌。
这是定义它的一种方式,但也许不是最好的。除了为您生成 SQL(例如,缓存、标记“脏”字段等)之外,ORM 层还可以做很多事情。当您实现 ORM 的所有功能时,用精心制作的 SQL 编写的“瘦”层可能会变得非常臃肿正在提供。
【讨论】:
我认为这种情况下的“瘦”是指:
编写 SQL 确实符合这个要求,但它也没有理由不能成为 ORM,尽管我想到的大多数 ORM 并不像轻量级那样让我印象深刻。
【讨论】:
我认为这取决于上下文。
这很可能意味着,或者它可能只是意味着您的业务对象直接映射一个简单的底层关系表结构:每个类一个表,每个类属性一个列,以便将业务对象结构转换为数据库表结构“薄”(即不复杂)。当然,这仍然可以由 ORM 处理。
【讨论】:
这可能意味着数据库上没有使用或使用最少的逻辑,例如避免使用存储过程。正如其他人所提到的,这取决于语句的上下文,最可能的含义。
【讨论】:
我认为数据访问总是应该很薄...... DAL 并不是真正有逻辑的地方。
也许与您交谈的人正在谈论业务层和数据访问层的组合;业务层不存在的地方(例如,一个非常简单的应用程序,或者可能所有业务规则都在数据库中,等等)。
【讨论】: