Java Dao类的单一责任原则

这是一个没有遵循单一责任原则的示例代码

public class EmailSender
{
  public void SendEmail(string customerID, 
                       string emailNotificationType)
  {
    //STEP1: load customer details
    //STEP2: get email content
    //STEP3: send email (using SmtpClient class)
  }

  public string GetEmailContent(Customer customer, 
                 string emailNotificationType)
   {
    // Build the email notification content
   }
}

我同意，如果我需要执行以下操作，它将产生问题

-> Changes in the way, you are loading customer details.

-> Changes to the email content because of requirement enhancements / changes.

-> If there any change in the way you are sending the email instead of using SmtpClient class or something like that.

因此，我们需要应用单一责任原则来划分类别。我完全同意这个原则。假设我需要创建三个类，如

EmailSender-只专注于发送电子邮件 CustomerRepository-只关注获取客户数据 EmailContentBuilder-用于解析电子邮件内容

但是如果我有一个像CustomerDao这样的Dao，那么到目前为止，我在同一个类中拥有了与CustomerDao相关的所有CRUD操作，如下所示

客户道类
-添加（）
-更新（） -get（）
-getAll（）
-更新（）

我们需要在这里应用单一责任原则吗？如果是，如何申请CustomerDao课程

谢谢，

---

Harry

您不想应用到DAO，因为它只做一件事

模式和原则是伟大的东西，但如果使用不当，它们会使一个简单的问题变得和没有它们一样复杂

SRP不应被严格理解。一个对象应该承担很少的责任，而不是“一个”。

---

这里的客户道只负责客户持久性，因此它只有一个责任。

尽管其名称SRP表示为“”。更改DAO的原因只有一个：当数据库表和业务对象之间的映射发生更改时，DAO不会违反SRP

考虑一个例子：业务逻辑更改，因此我们需要向对象添加更多数据：我们向业务对象添加字段，向数据库表添加列，当然我们需要更改映射。然后，我们可能会更改单个DAO类的get/add/update方法

---

为了更清楚地理解这一原则，我建议阅读《可靠原则》的原始来源：罗伯特·马汀的书。

我认为这可能更适合你的问题。@abra，IMHO，这也是一个我相信的程序性问题，请让我知道你对客户的看法。请检查这一点，在正确的抽象级别应用模式是很重要的

CRUD

如果在单个类中使用，则很好，是的，您做得很好。除非您已经准备好为小型操作维护该级别的代码库，否则不要将大量责任委托给其他类。和

邮件发件人

可以是静态的，并且可以用作util类：）