Asp.net Windows服务或WCF服务

我需要实现简单的文件监视工具。我决定在一个简单的windows服务中实现这一点，该服务将在内部使用FileSystemWatcher。其目的是监视给定的目录路径（或ftp），并在检查一些预定义逻辑后，将文件复制到任何新文件进入的其他服务器

当我使用.NET3.5时；客户建议我使用WCF。我在WCF方面的经验很少

我不确定如何创建WCF服务，该服务的功能类似于WindowsService，并且可以部署在windows server上的服务中

---

作为一个未来派，创建WCF服务而不是windows服务是一个好主意，还是我应该坚持使用windows服务。

您应该选择最简单的选项，直到您发现需要更改为止，最简单的选项是windows服务

在这种情况下，有一个称为YAGNI的编码原则（您不需要它）适用，因为简单地将某些东西包装到WCF服务中只会为大多数情况增加不必要的复杂性。简单地说，做最小可行的解决方案，只在需要时扩展

---

另外，如果您通过网络共享使用FileSystemWatcher，请注意它存在文档记录的问题，您应该结合使用轮询+FileSystemWatcher。关于堆栈溢出有很多解释。

在您的用例中，Windows服务更有意义，我认为这是更合适的解决方案。您需要一些始终运行和监视目录的东西，而这正是Windows服务非常擅长的用例

---

我会考虑与客户交谈，并解释Windows服务是对这种用例的更合适的解决方案。而且，windows服务并不是老帽子，它们的存在正是为了解决这些类型的用例，而WCF/windows服务是相辅相成的

这两个功能的名称中都有服务，实际上它们没有任何共同之处

Windows服务在一台机器上持续运行

---

WCF服务是其他机器无法远程调用的代码。

它只取决于您需要做什么。Windows服务和“WCF服务”几乎没有共同之处

这里的问题是您是否需要HTTP端点。如果您这样做了，您甚至可以在windows服务中托管一个WCF服务来提供该服务。请记住，WCF仅用作应用程序之间通信的一种方式

然而，阅读你的描述，你似乎并不需要它

---

Windows服务！=WCF

您不能创建像windows服务一样运行的WCF服务。WCF服务等待来自第三方的消息并对其进行操作，windows服务是始终在后台运行的进程。WCF试图解决将通信机制（如Tcp、Http、命名管道等传输协议）与服务接口分离的问题

文件监视程序实用程序

虽然理论上可以在WCF中创建一个新的平面文件绑定，“可以”将其地址设置为文件系统位置，但是.NET framework中并不直接存在这样的绑定。看看MSDN上的文章，我并不清楚如何构建文件系统绑定。以下是已定义的可用传输选项：

TCP

HTTP

HTTPS

命名管道（IPC）

点对点（P2P）

消息队列（MSMQ）

习俗

若通信必须通过文件删除完成，那个么WCF并不能解决您的问题

WCF可能工作的地方

客户端的意思可能是创建一个WCF端点，在检查一些预定义的逻辑后，

将文件复制到任何新文件进入的地方，
将文件复制到其他服务器上，但您仍然希望有一个带有
FileWatcher
监视输入目录的windows服务

如果您有多个客户机需要能够执行相同的逻辑，然后将输出发送到另一台服务器，那么创建WCF服务可能是有意义的，否则在这一点上它是过度设计的