WCF是长数据导入过程的正确选择吗？

Question

我正在为我们的业务创建一个流程,它从数据库中获取一些数据(A),对数据进行一些处理,然后将其复制到另一个数据库中的另一个表中(B).我们处理的数据量很大,我们预计此过程需要很长时间(数周).

对于使用WCF这类任务来说,这是一个明智的设计选择吗？这样我认为我可以使用某种客户端应用程序/ Web前端(业务的其余部分可以使用)来"查询"/显示整个导入过程的进度.我还想让客户能够通过服务启动/暂停/停止导入过程.

这可以在WCF中使用吗？这是否是正确的选择？我想在某些方面,这需要像常规Windows服务一样(我只是认为通过WCF通过某些方法"查询"导入的进度会更容易吗？)

另外,如果一个用户试图同时启动/停止导入过程等,我是否会遇到问题？单例模式是否适用于确保每个人都使用相同的单一导入过程？

任何想法/想法都非常感谢.

Answer 1

编辑/前言：这个答案假设您只想使用 WCF 进行用户与进程的交互，而不是整个软件堆栈的通信，并且核心工作是由长期运行的服务本身完成的。

是的，这在 WCF 中是可行的，而且可能是正确的解决方案。您将拥有一个长时间运行的处理器线程，该线程经常查询/更新某些互操作属性集（例如，它将更新完成的百分比、正在处理的项目以及检查“暂停”标志等.)。这些属性将依次由 WCF 接口方法查询/设置。

单例模式非常适合这种情况 - 如果您的线程设置正确，用户将与长时间运行的线程（或多个线程）检查的某些属性进行交互。

从极高层次的角度来看，处理器类的核心可能看起来像这样（这只是一个如何完成它的模型；不要完全像这样，否则我会做噩梦）：

// IWcfProcessor is the ServiceContract interface
// Processor runs as a singleton and does (or has a thread that does) the processing work
class Processor : IWcfProcessor
{
    public Processor()
    {
        new Thread(Process).Start();
    }

    public void Process()
    {
        while (Run)
        {
            // Do long-running process stuff, update some tables
            PercentDone += 0.1;
        }
    }

    public decimal PercentDone { get; set; }
    public bool Run { get; set; }

    /// WCF method defined in IWcfProcessor
    public void SetState(bool state)
    {
        Run = state;
    }

    /// WCF method defined in IWcfProcessor
    public decimal GetStatus()
    {
        return PercentDone;
    }
}

IWcfProcessor然后，您可以从 Web 或应用程序端点连接到接触点。

另外，我是否会遇到问题，例如，如果一个用户尝试同时启动/停止导入过程等？

假设您正确设置了线程互操作，就不会有问题。

单例模式是确保每个人都使用相同的单一导入流程的方法吗？

是的，这很完美。