【问题标题】:Does a "thin data access layer" mainly imply writing SQL by hand?“瘦数据访问层”是否主要意味着手动编写 SQL?
【发布时间】:2023-03-10 10:40:01
【问题描述】:

当您说“精简数据访问层”时,这是否主要意味着您是在谈论手动编写 SQL,而不是依靠 ORM 工具为您生成它?

【问题讨论】:

    标签: terminology data-access-layer


    【解决方案1】:

    这可能取决于谁说的,但对我来说,薄的数据访问层意味着该层几乎没有额外的逻辑(即数据存储抽象),可能不支持针对多个 RDBMS,没有层-特定缓存,无高级错误处理(重试、故障转移)等。

    由于 ORM 工具倾向于提供其中的许多功能,使用 ORM 的解决方案可能不会被视为“瘦”。许多本土数据访问层如果提供上述功能,也不会被视为“瘦”。

    【讨论】:

    • 您似乎在说它不代表什么,但没有指定它必须包含什么。是不是因为这个词本身就含糊不清?
    • 究竟什么是“薄”层是主观的,而不是模糊的。唯一必须包含在应用程序表示(通常是业务对象)和数据表示(通常是 SQL 表)之间移动数据的代码。
    【解决方案2】:

    取决于我们如何定义“瘦”这个词。这是我听到的最被滥用的术语之一,只有“轻量级”才能与之匹敌。

    这是定义它的一种方式,但也许不是最好的。除了为您生成 SQL(例如,缓存、标记“脏”字段等)之外,ORM 层还可以做很多事情。当您实现 ORM 的所有功能时,用精心制作的 SQL 编写的“瘦”层可能会变得非常臃肿正在提供。

    【讨论】:

    • 您是否使用“ORM 层”作为“数据访问层”的同义词?我认为两者之间有更明显的区别?
    • 不,ORM 是实现数据访问层的一种方式。将数据访问层视为类或接口,将 ORM 视为它的特定实现。
    【解决方案3】:

    我认为这种情况下的“瘦”是指:

    1. 重量轻;
    2. 性能开销低;和
    3. 您编写的代码最少。

    编写 SQL 确实符合这个要求,但它也没有理由不能成为 ORM,尽管我想到的大多数 ORM 并不像轻量级那样让我印象深刻。

    【讨论】:

    • 所以当您谈到数据访问层时,ORM 可能就是您的意思吗?我认为 ORM 的作用和数据访问层的作用之间存在某种细微的差别——尽管我不能告诉你它是什么 :-)
    • 数据访问层只是一种简化对持久存储的访问的方法。 ORM 也符合该描述。这其中的“薄”部分是主观测试。
    • 所以你的意思是,当有人说数据访问层“薄”时,这真的取决于一个案例到下一个案例的真正含义,因为某些 ORM 可能比其他 ORM 具有更多功能。
    【解决方案4】:

    我认为这取决于上下文。

    这很可能意味着,或者它可能只是意味着您的业务对象直接映射一个简单的底层关系表结构:每个类一个表,每个类属性一个列,以便将业务对象结构转换为数据库表结构“薄”(即不复杂)。当然,这仍然可以由 ORM 处理。

    【讨论】:

    • 所以当您说“薄数据访问层”时,ORM 可能就是您的意思,但这取决于 ORM 的全功能——只有极简的 ORM 才有资格?这似乎是一个很难定义的术语。也许只是含糊不清,意义不大。至少这就是我在这里得到的。
    【解决方案5】:

    这可能意味着数据库上没有使用或使用最少的逻辑,例如避免使用存储过程。正如其他人所提到的,这取决于语句的上下文,最可能的含义。

    【讨论】:

    • 为什么没有存储过程意味着数据访问层很薄?
    【解决方案6】:

    我认为数据访问总是应该很薄...... DAL 并不是真正有逻辑的地方。

    也许与您交谈的人正在谈论业务层和数据访问层的组合;业务层不存在的地方(例如,一个非常简单的应用程序,或者可能所有业务规则都在数据库中,等等)。

    【讨论】:

      猜你喜欢
      • 2018-07-12
      • 1970-01-01
      • 2021-10-01
      • 1970-01-01
      • 2020-07-29
      • 1970-01-01
      • 2014-08-15
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多