我一直在研究设计模式,我希望在我的最新项目中实现它们。
我正在开发一个Windows服务,它定期检查数据库表中的一个新条目。根据找到的条目,服务将执行许多进程。
可能的程序包括:
1)生成报告并发送电子邮件并附上报告。
2)运行查询并将数据记录到另一个表。
3)发送通知电子邮件
什么样的设计模式最适合?我一直在考虑工厂模式。
到目前为止我的设计过程..。
1)创建接口
2)创建实现接口的抽象类
3)抽象方法:
- CheckTable()
- GenerateReport()
- SendEmail()
4)工厂设计模式:
- The client(windows service) asks the Factory for a new object (based of the database entry found)
- The factory instantiates this and returns to the client
- The client then calls the relevant methods to send email or run query.
这个看起来对吗?还是我让事情变得比现在更困难了?
还是我应该使用观察者模式?
好的。我接受了你的建议,并寻找最简单的方法来做这件事。
下面的内容正确吗?我创建了一个接口,然后创建了一个类来实现这个接口。
可能会产生一些不同的报告/电子邮件。这些应该作为新方法添加到接口中吗?
我需要一个抽象的课程吗?
// interface
internal interface IJobs
{
void SendEmail();
void PublishData();
void GenerateTestReport(string userID, DateTime period);
}
// concrete class
public sealed class JobsFactory : IJobs
{
#region SINGLETON
private static JobsFactory INSTANCE;
private JobsFactory() { }
public static JobsFactory GetInstance()
{
if (INSTANCE == null)
{
INSTANCE = new JobsFactory();
}
return INSTANCE;
}
#endregion
private readonly WorkbookFactory _workbookFactory = WorkbookFactory.GetInstance();
#region IJobs Members
public void SendEmail()
{
// send email
}
public void PublishData()
{
// publish data
}
public void GenerateTestReport(string userID, DateTime period)
{
string reportTestFilePath = this._workbookFactory.BuildTestReportWorkbook(userID, period);
}
#endregion
}
发布于 2015-01-12 04:19:16
我给你讲个故事。许多年前,当我还是一名年轻的、缺乏经验的程序员时,GoF不久就出版了他们的“设计模式”( Design )一书,而Java是一种新的语言,也是唯一一个普遍可用的用户界面库,因为它是AWT,而且AWT应用程序看起来都很难看,我的公司决定将开发从C++转向Java。但是AWT是不可能的:我们的应用程序被要求看起来和感觉就像本地的Win 32应用程序,而你不能用AWT实现这一点。因此,我的任务是学习JNI,并实现一个框架,允许我们使用Java构建本机windows用户界面。
不久之前,我就读到了有关的文章,并且渴望使用它们,所以我查看了我的项目,并考虑了哪些项目适合在哪里使用。我最自豪的想法是:我有一个本机窗口对象,它封装了一个win32窗口句柄,但是为了允许应用程序将行为附加到窗口,我会使用责任链。这将让应用程序使用现有的行为并以新的方式组合它们,一切都会很棒。
所以我实现了责任链,它比只有一个行为对象来管理一切要复杂一些,但是我用它编写了几个测试,一切都运行得很好。
然后我们部署了框架,并开始使用它编写真正的应用程序,您知道吗?我们从未使用过该工具在一个窗口中链接多个行为。
这里的教训很简单:不要从使用Design目录开始在应用程序中购买额外的灵活性。首先考虑您真正需要的灵活性,然后考虑如何实现这种灵活性。也许标准模式是实现这一目标的最佳方式。也许有一种更简单、更直接的方法。甚至可能会出现这样的情况:您有一个僵化的、定义明确的问题,这个问题足够小,您可以简单地设计整个解决方案,而不需要任何空间来改变以后的行为,在这种情况下,任何类似于设计模式的事情都可能会造成过度的后果。
借用肯特·贝克( Kent Beck )的一句话:“做最简单的事情,这可能会奏效。”如果这看起来像一种模式,那就太好了。但如果不是的话别担心。
发布于 2015-01-12 09:00:47
我一开始就不使用任何模式。
var records = CheckTable();
foreach(var record in records)
{
GenerateReport(record);
SendEmail(record);
}
一开始很简单,并不是每件事都需要一个模式。如果您开始执行许多不同的任务,或者允许按顺序配置任务和每个记录中运行的任务数,那么可以考虑通过重构将其抽象出来。
发布于 2015-01-12 04:03:16
由于您需要执行似乎是轮询的操作,所以您可以查看一下Observer Pattern
。这将允许您的服务调用您的方法,以便它们能够采取适当的操作。
尽管如此,正如评论中提到的那样,您似乎拥有相反的设计模式。这个任务应该引导你进入一个设计模式。试图将您的需求封装在特定的设计模式中并不是处理设计的最佳方法。
https://softwareengineering.stackexchange.com/questions/269808
复制