假设我们有一个运行CommandRunner的{{1}}类，当创建Commands时，如果执行{{1}，它将保留在Command中以进行处理如果错误已完成processingQueue移至Command以供稍后处理，但当一切正常时，Command会移至faultedQueue，Command不会以任何方式处理
CommandRunner就是这样的
archiveQueue archiveQueue以class CommandRunner
{
public CommandRunner(IQueue<Command> processingQueue,
IQueue<Command> faultedQueue,
IQueue<Command> archiveQueue)
{
this.processingQueue = processingQueue;
this.faultedQueue= faultedQueue;
this.archiveQueue= archiveQueue;
}
public void RunCommands()
{
while(processingQueue.HasItems)
{
var current = processingQueue.Dequeue();
var result = current.Run();
if(result.HasError)
curent.MoveTo(faultedQueue);
else
curent.MoveTo(archiveQueue);
...
}
}
}
CommandeRunner为PersistentQueue的{{1}}长期存储，以PersistentQueue为对象，我们将Commands作为CommandRunner。处理这个
archiveQueue的唯一目的是保持设计的同质性，以保持CommandRunner持久性无知且依赖性很小
例如，我们可以设想像这样的属性
IEnumerable<Command> AllCommands
{
get
{
return Enumerate(archiveQueue).Union(processingQueue).Union(faultedQueue);
}
}
该类的许多部分需要这样做（将Archive作为队列处理以使代码更简单，如上所示）
使用队列是否有意义，即使它不是最好的抽象，或者我是否必须使用另一个抽象来存档概念。 有哪些其他替代方案可以满足这些要求？
答案 0 :(得分：1)
请记住，随着时间的推移，代码，尤其是运行代码通常会变得混乱和混乱。为了解决这个问题，好的名字，好的设计和有意义的评论都会发挥作用。
如果您不打算处理archiveQueue，并且它只是已成功处理的邮件的存储空间，您可以随时将其存储为其他类型（列表，集合，集合，适合您的任何内容）需要），然后选择以下两个之一：
保留名称archiveQueue并更改基础类型。我会在定义（或注入）的地方留下评论说：请注意，这可能不是实际的队列。名称仅用于一致性原因。
在保留队列类型的同时，将名称更改为archiveRepository或类似名称。显然，由于它仍然是一个队列，你会发表评论说：注意，这实际上是一个队列。
要记住的另一件事是，如果您有n个人在处理您的代码库，那么您可能会得到n+1不同的关于应该采用哪种方式的权限：）
答案 1 :(得分：0)
当您需要关注其中的项目顺序时，队列是一个有用的结构。如果你需要在你的命令发布过程中，注意命令命令运行，那么队列可以是一个不错的选择。
如果您不需要有关订单或命令的信息，也许您可以使用List（在System.Collections命名空间中）。
我认为你的选择是好的，在相同的情况下，我会使用队列，我们有一个很好的OS设计原则示例，在OS内部（在内核上）进程排队等待执行，显然是操作系统队列更复杂，因为它们有其他变量，如优先级和CPU利用率，但我们可以了解在进程管理中使用数据结构等队列。