我无法在两种可能的设计选择之间做出选择。我有一个网站，它有一个相当广泛的业务层和 DAL(网站、bll 和 dal 都在多个单独的 dll 中)。我需要设计一个 Windows 服务，它可以获取我的一些业务对象，将它们写入文件，然后将它们存储在本地网络中。然后将这些文件导入第 3 方程序，该程序会对它们进行进一步处理。
我可以通过以下两种方式之一设计此服务:
围绕业务层和 DAL 包装服务。这将是快速和容易的，但缺点是每次业务层发生变化时，服务都必须更新。
向网站添加网络服务，然后只需查询网络服务以获取我需要的内容。 Windows 服务不必使用业务层，只要 Web 服务不变，我就可以了。唯一的缺点是我可能必须创建一些基本的业务对象来将 Web 服务的 xml 解析成。
Windows 服务必须每 10-20 分钟左右轮询一次业务层/dal 或 Web 服务。 Windows 服务是必需的，因为该网站是异地托管的，因此无法访问我们的任何本地资源。我倾向于选项 2，但我被撕裂了。
给定两个选择，哪个是更好的选择？还有其他我没有考虑过的可能选择吗？此外，对于拥有一组主要由网站使用但最终可能用于数据检索或执行某些功能的核心库的情况，您通常如何设计？
我不确定将某些业务对象作为文件存储在网络上的标准是什么，但如果您定期这样做，那么大概您正在尝试跟踪某种变化，所以还有另一个解决方案:将逻辑直接构建到业务/持久层。
如果这种辅助文件存储是一项业务需求，那么它应该直接嵌入该层并由某种事件触发。这样一来，您就只有一个连贯的系统，而不是拥有一个本质上可能与系统的其余部分不同步的临时后处理作业。
反转设计 - 不是围绕业务服务包装网络服务并将其用于临时报告，而是创建一个网络服务来封装您需要从导出中接收的数据定期，并让您的业务层在新数据准备就绪时向其发送消息。您可以异步发送消息，以免占用业务服务，并且根据您的可靠性要求，您可以设置一个消息队列(这比听起来容易，WCF 已经知道如何使用 MSMQ 作为传递机制，它只是一个需要更改的配置设置很少)。
如果不了解更多关于架构、数据量和类型、调度和报告要求等的信息，我不能肯定地说这比你的前两个选项更好，但它是一些东西你应该考虑。如果您认为您的业务服务可能会相当频繁地更改，那么将数据向外推送到“仓库”类型的抽象而不是通过挖掘过程来提取数据可能会更好。
否则，我想我会选择选项 2。我不知道您以前是否使用过 WCF 服务，但您应该知道您实际上不必解析 XML。一切都是通过数据契约完成的，当您为 Web 服务生成代理时，您将获得强类型的 .NET 对象。如果您可以直接通过服务 API 传递您的领域对象，那么创建 Web 服务真的非常简单。
Web 服务的真正缺点是您必须采取措施确保您的服务契约(Contract)永远不会发生重大变化(否则它可能会破坏客户)。因此，您可能最终需要在服务端创建数据传输对象以用作公共(public) API，而不是通过域对象传递。但在很多情况下，您很长一段时间都不需要这样做，所以请继续尝试一下，您会发现它非常简单。