采取哪种 DAL 方法？

Posted 2023-04-12

【中文标题】采取哪种 DAL 方法？

【英文标题】：Which DAL approach to take?

【发布时间】：2010-08-06 16:27:16

【问题描述】：

ActiveRecord 通常限制太多。但是，就团队中每个成员对使用 ORM 的看法而言，我处于一个困难的境地。我们目前使用一个非常基本的 ActiveRecord，遗憾的是我说它主要是用一些基本的代码生成的手工编写的。我想为我们构建一个新的 DAL，但要避免 ActiveRecord 的限制，所以 DDD 更是如此。然而，我要与之抗争的要点是（老 skool 开发人员和我自己都很年轻）：

团队首席开发人员

支持存储过程，但不一致...有些只是得到 一张桌子，例如SELECT * FROM Company 和一些得到 SELECT C.*, O.OtherTableValue FROM Company C...（非常令人沮丧） 不太了解某些最新 ORM 工具的好处 不会承诺任何工具，因为它“限制性太强”，如果有 问题你是做什么的？

DBA

不喜欢动态 SQL 不喜欢 SELECT *

我并不是说以上内容是禁区，否则更能说服他们。我相信我们可以通过使用 ORM 大大提高我们的效率，但很难说服他们。如果我能证明其中一些领域，我或许能够说服他们，即使在他们不知道的情况下在幕后实施，然后看到好处。

您可以提供什么建议来帮助解决我的情况？我相信很多开发者都会遇到这种情况，无法选择他们想要使用的架构。

【参考方案1】：

我认为您的团队负责人需要致力于一致性或花一些时间在 ORM 研究项目上提出使用建议。换句话说，一个前后不一的团队负责人不应该担任这个角色。

其次，出于多种原因，我倾向于同意您的 DBA。只要他/她足够灵活，知道在某些情况下动态 SQL 会更好地解决问题。

对于您的具体情况，我想说请您的 DBA 制定每次都应使用存储过程的法律，除非逐案提供理由，并通过政策和监控强制执行。这将解决一致性问题。也许到那时，有了这个政策，ORM 看起来比必须将所有内容都手动编码给 Team Lead 更有吸引力。

【讨论】：

关于团队负责人 - 他不会改变自己的方式，他对这份工作没有真正的兴趣来让事情变得更好......更多的是'那会做'。我认为不应该做这份工作，但这不是我的要求，所以我必须凑合。关于 DBA，他并没有真正从应用程序中得到问题，因为数据库是他的背景，我认为他学到了一点，从那以后还没有，因此还没有了解新的变化，即动态 sql 现在并不“总是”不好..

那我建议你读一读《死亡行军》这本书。可能会对您的情况有所帮助。

看起来像是新的 DAL 或其他工作

【参考方案2】：

首席开发人员应听取 DBA 的意见。 "SELECT *" 不好。从关于首席开发人员的要点来看，听起来你已经经历了一场熟悉的艰苦战斗。有时，在这种情况下阻力最小的路径是使用 ORM（例如 NHibernate）实现某些东西，并为团队安排某种演示。

鼓励他们提出意见，特别是来自首席开发人员和 DBA 以及任何其他反对者的意见。当您了解更多有关该工具的信息时，他们可能有合法的抱怨，实际上可以使用该工具解决。另一方面，他们可能只是无缘无故地反对它。如果是这样的话，最好找出来，因为这很可能意味着在反对他们的论点上没有胜算，因为他们并没有真正在辩论。

【讨论】：

它并没有真正辩论......正如我在上面评论的那样，他们学到了一些东西并且没有说 5-10 年，并且认为这仍然是最好的方法。我认为我想要赢得和改进的唯一方法就是推出我自己的 DAL .. 但它从哪里开始，这是一项艰巨的任务。我知道人们说不要，但我真的认为我没有太多选择:(

【参考方案3】：

他们对使用 ORM 有什么反对意见？如果他们不只是固执和固执，那么如果你知道他们具体反对你什么并解决这些问题。和其他人一样，我认为您的 DBA 是正确的。但如果他担心动态 sql 的 SQL 注入，ORM 会在一定程度上缓解这个问题。选择 * 应该是解雇的理由。

我认为你应该只使用一些东西，LINQ-to-SQL 或 subsonic 或 nhibernate 在一些小的东西上。表明使用 ORM 可以更快、更清洁地进行开发。

【讨论】：

关于创建一个新的 DAL，ORM 最好基于它...？如果它看起来是我创建的，那么他会使用它，所以只需要一个起点，调整它并从其他 ORM 中获取一些想法。 Subsonic 似乎是一个简单的代码库..想法？