采用哪种 DAL 方法？

Question

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

团队首席开发人员

• 赞成存储过程，但不一致......有些只是得到 一个表，例如 SELECT * FROM Company，有些得到 SELECT C.*, O.OtherTableValue FROM Company C...（非常令人沮丧）
• 并不真正了解某些最新 ORM 工具的好处
• 不会承诺使用任何工具它“限制太多”，如果有 问题你做什么？

DBA

• 不喜欢动态 SQL
• 不喜欢 SELECT *

我并不是说以上内容是禁止的，否则更能说服他们。我相信我们可以通过使用 ORM 来大幅提高效率，但很难说服他们不这样做。如果我能够在其中一些领域提供证据，我也许能够说服他们，即使是在他们最初不知道然后看到好处的情况下秘密实施。

您可以提供什么建议来帮助我的情况？我相信很多开发人员都遇到过这个问题，并且无法选择他们想要使用的架构。

Answer 1

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

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

对于您的具体情况，我会要求您的 DBA 制定法律，规定每次都使用存储过程，除非根据具体情况提供理由，并通过策略和监控来强制执行。这将解决一致性问题。也许有了这个政策，ORM 看起来比必须向团队负责人手动编写所有内容更具吸引力。

Answer 2

首席开发人员应该听取 DBA 的意见。 “SELECT *”不好。从首席开发人员的要点来看，这听起来像是一场熟悉的艰苦战斗。有时，在这种情况下阻力最小的方法是使用 ORM（例如 NHibernate）实现某些内容，并为团队安排某种演示。

鼓励他们的意见，特别是来自首席开发人员和 DBA 以及任何其他反对者的意见。他们可能有合理的抱怨，随着您对该工具的了解更多，这些抱怨实际上可以通过该工具得到解决。另一方面，他们可能只是因为没有充分的逻辑原因而坚决反对。如果是这样的话，最好找出来，因为这很可能意味着在这场针对他们的争论中无法获胜，因为他们并没有真正进行辩论。

Answer 3

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

我认为你应该在一些小东西上使用 LINQ-to-SQL 或 subsonic 或 nhibernate。表明使用 ORM 可以使开发更快、更干净。