与数据库交互的类的命名规范

Question

是否存在一种标准的命名约定，用于与数据库交互的类（CRUD操作或检查重复项）？目前，我只是将其命名为Helper，例如，如果一个名为“Subscriptions”的类与该表交互，则将命名为“SubscriptionHelper”。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace LoopinWineBackOffice.Helper
{
    public class SubscriberHelper
    {
        public static bool IsEmailAlreadyInUsed(string email)
        {
            using (var dc = new LoopinWiineContainer())
            {
               return dc.Subscribers.Any(item => item.Email==email.Trim());
            }
        }
    }
}

我的示例代码大致如下。

- Sarawut Positwinyu

Answer 1

根据我的经验（无意冒犯），当类的名称开始变得像“Helper”和“Manager”时，这是因为该类的目的没有被很好地定义（我过去也有过这样的错误）。

在这种情况下，我认为您没有真正考虑您的数据访问模式，而只是在“SubscriptionHelper”类中使用了一堆临时SQL查询。

现在，如果您正在实现标准的数据访问模式，例如存储库模式，那么您的类将被称为SubscriptionRepository，并且其意图将更加清晰。

所以，回答这个问题-不，我不认为有一个标准的“命名”约定适用于您的情况。然而，有几种标准的设计模式可以潜在地应用于您的系统，并通过这样做，您可能会最终拥有一个既信息丰富又有意义的命名约定。

以下是一些著名设计模式的起点：http://martinfowler.com/eaaCatalog/，但如果没有更多关于项目的信息，就很难给出更进一步的指导。

- RJ Lohan

---

我同意 - 你应该考虑模式而不是命名约定。例如MVC或Repository。在.Net中也有很多数据框架 - EF - LINQ - ADO ... - SyntaxGoonoo

我认为，拥有一堆仅与数据交互的函数并不可耻。我经常这样做，当它们的共同目的变得清晰时，我会进行重构，使其更有意义。 - Ally

我同意，一开始就试图以某种特定方式布置代码很容易陷入泥潭。通过不断测试和重构，让代码成为它需要的架构。应该产生良好定义的代码组合，易于阅读并存在于一个明确的目的中。最终意味着随着时间流逝，命名变得更加容易。然而，这种方法的关键是测试和重构，这必须成为日常编码的一部分，否则这种方法将失败。 - Jeremy

Answer 2

有没有与数据库交互的类的标准命名规范？

是的，可以遵循“表数据网关”模式，例如您可以为访问单个表或视图的“订阅者网关”对象命名：选择、插入、更新和删除。

表数据网关（Table Data Gateway）：作为访问数据库表的网关的对象。 http://martinfowler.com/eaaCatalog/tableDataGateway.html

- ChatGPT