Rom*_*man 5 java architecture oop dependency-injection
我有一个带有Spring IoC容器的Java EE项目.
我刚刚在Utils类静态方法中找到了sendMail(long list of params).我不知道为什么,但我觉得如果我们有单独的类(具有单例范围的Spring bean)将负责发送电子邮件会更好看.但我找不到任何可以证明我立场的论据.
那么,在这种(相当普遍的)情况下使用DI有任何优点(或缺点)吗？
包含通常静态函数的混杂的 Util 类型类通常不是什么好东西。我什至在我参与的一个项目中看到过这种名为 UglyGlobals 的类。至少他们是诚实的！一般来说，你是对的。像邮件这样的东西是一个很好的候选者，可以变成一个被注入的单例 bean。
如果需要发送电子邮件的类使用MailSender接口(样本名称)而不是static Utils.sendMail(...)方法,那么您可以通过在单元测试中交换模拟/不同实现MailSender而不是使用真实实现来轻松地对这些类进行单元测试.
这允许您在邮件发送成功,捕获异常/错误等时测试这些类的行为.
如果类使用的是静态方法,就像你所描述的那样,那么你就不能在不实际发送电子邮件的情况下单独测试这些类的行为 - 此时它不是一个有效的,独立的单元测试,因为你现在依赖于1)邮件发送代码2)外发邮件服务器等的行为
是! 我会根据自己最近的经历给你一个例子.
我们最近将一堆应用程序从直接发送电子邮件切换到使用数据库队列发送消息.消息在DB中排队,然后通过批处理发送.这使我们能够处理SMTP服务器中断,重新发送消息,控制可以从我们的开发服务器发送的消息,验证消息是否实际发送等.
像发送电子邮件这样简单的东西肯定是您将来可能想要改变的东西.注入实现会使这样做更容易.
| 归档时间： |
|
| 查看次数： |
2417 次 |
| 最近记录： |