对于 T4 模板的 Azure 队列构建来说，这是一个好的/优选的模式吗？

Question

我正在构建一个 T4 模板，它将帮助人们以一致且简单的方式构建 Azure 队列。我想让这个自我记录，并且保持一定的一致性。

1. 首先，我在文件顶部创建了队列名称，队列名称必须为小写，因此我添加了 ToLower()

2. 公共构造函数使用内置的 StorageClient API 来访问连接字符串。我已经看到了许多不同的方法，并且希望找到一种适用于几乎所有情况的方法。 （想法？分享）

3. 我不喜欢不必要的 HTTP 请求来检查队列是否已创建，因此我创建了一个 static bool 。我没有实现 Lock(monitorObject)，因为我认为不需要。

4. 我不是使用字符串并用逗号解析它（像大多数 MSDN 文档一样），而是在将对象传递到队列时序列化该对象。

   而不是使用

5. 为了进一步优化，我使用 JSON 序列化器扩展方法< /a> 充分利用 8k 限制。不确定编码是否有助于进一步优化

6. 添加重试逻辑以处理队列中发生的某些情况（请参阅 html 链接）

7. 问：“DataContext”是否适合此类的名称？

8. 问：按照我的方式命名队列操作名称是一个不好的做法吗？

您认为我还应该做哪些额外的改变？

public class AgentQueueDataContext
{
    // Queue names must always be in lowercase
    // Is named like a const, but isn't one because .ToLower won't compile...
    static string AGENT_QUEUE_ACTION_NAME = "AgentQueueActions".ToLower();

  static bool QueuesWereCreated { get; set; }

    DataModel.SecretDataSource secDataSource = null;

    CloudStorageAccount cloudStorageAccount = null;
    CloudQueueClient cloudQueueClient = null;
    CloudQueue queueAgentQueueActions = null;

    static AgentQueueDataContext()
    {
        QueuesWereCreated = false;
    }

    public AgentQueueDataContext() : this(false)
    {
    }
    public AgentQueueDataContext(bool CreateQueues)
    {
        // This pattern of setting up queues is from:
        // ttp://convective.wordpress.com/2009/11/15/queues-azure-storage-client-v1-0/
        //
        this.cloudStorageAccount = CloudStorageAccount.FromConfigurationSetting("DataConnectionString");
        this.cloudQueueClient = cloudStorageAccount.CreateCloudQueueClient();
        this.secDataSource = new DataModel.SecretDataSource();

        queueAgentQueueActions = cloudQueueClient.GetQueueReference(AGENT_QUEUE_ACTION_NAME);

        if (QueuesWereCreated == false || CreateQueues)
        {
            queueAgentQueueActions.CreateIfNotExist();
            QueuesWereCreated = true;
        }
    }

  // This is the method that will be spawned using ThreadStart
   public void CheckQueue()
    {
        while (true)
        {
            try
            {
                CloudQueueMessage msg = queueAgentQueueActions.GetMessage();

                bool DoRetryDelayLogic = false;

                if (msg != null)
                {
                    // Deserialize using JSON (allows more data to be stored)
                    AgentQueueEntry actionableMessage = msg.AsString.FromJSONString<AgentQueueEntry>();

                    switch (actionableMessage.ActionType)
                    {
                        case AgentQueueActionEnum.EnrollNew:
                            {
                                // Add to 
                                break;
                            }
                        case AgentQueueActionEnum.LinkToSite:
                            {
                                // Link within Agent itself

                                // Link within Site

                                break;
                            }
                        case AgentQueueActionEnum.DisableKey:
                            {
                                // Disable key in site

                                // Disable key in AgentTable (update modification time)

                                break;
                            }
                        default:
                            {
                                break;
                            }
                    }

                    //
                    // Only delete the message if the requested agent has been missing for 
                    // at least 10 minutes
                    //
                    if (DoRetryDelayLogic)
                    {
                        if (msg.InsertionTime != null)
                            if (msg.InsertionTime < DateTime.UtcNow + new TimeSpan(0, 10, 10))
                                continue;

                        // ToDo: Log error: AgentID xxx has not been found in table for xxx minutes.   
                        //                  It is likely the result of a the registratoin host crashing.
                        //                  Data is still consistent.  Deleting queued message.
                    }


                    //
                    // If execution made it to this point, then we are either fully processed, or 
                    // there is sufficent reason to discard the message.
                    //
                    try
                    {
                        queueAgentQueueActions.DeleteMessage(msg);
                    }
                    catch (StorageClientException ex)
                    {
                        // As of July 2010, this is the best way to detect this class of exception
                        // Description: ttp://blog.smarx.com/posts/deleting-windows-azure-queue-messages-handling-exceptions
                        if (ex.ExtendedErrorInformation.ErrorCode == "MessageNotFound")
                        {
                            // pop receipt must be invalid
                            // ignore or log (so we can tune the visibility timeout)
                        }
                        else
                        {
                            // not the error we were expecting
                            throw;
                        }
                    }
                }
                else
                {
                   // allow control to fall to the bottom, where the sleep timer is...
                }
            }
            catch (Exception e)
            {
                // Justification: Thread must not fail.
                //Todo: Log this exception

                // allow control to fall to the bottom, where the sleep timer is...
                // Rationale: not doing so may cause queue thrashing on a specific corrupt entry
            }

            // todo: Thread.Sleep() is bad
            //       Replace with something better...
            Thread.Sleep(9000);
        }

Answer 1

问：“DataContext”对于此类来说合适吗？

在 .NET 中，我们有很多 DataContext 类，因此从某种意义上说，您希望名称能够适当地传达该类的功能，我认为 XyzQueueDataContext 能够正确地传达该类的功能 - 尽管您无法查询从它。

如果您想与接受的模式语言更加一致，模式企业应用程序架构调用任何封装对网关外部系统的访问的类，而更具体地说，您可能希望在语言中使用术语通道 企业集成模式 - 这就是我要做的。

问：按照我的方式命名队列操作名称是不是一种不好的做法？

嗯，它确实将队列名称与类紧密结合。这意味着，如果您后来决定要将它们解耦，那是做不到的。

作为一般性评论，我认为这门课可能会从尝试少做一些事情中受益。使用队列与管理队列不同，因此我建议您注入 CloudQueue 到实例中，而不是在其中放置所有队列管理代码。以下是我实现 AzureChannel 构造函数的方法：

private readonly CloudQueue queue;

public AzureChannel(CloudQueue queue)
{
    if (queue == null)
    {
        throw new ArgumentNullException("queue");
    }

    this.queue = queue;
}

这更适合单一职责原则，您现在可以实现队列管理在其自己的（可重用）类中。