Web服务还是DLL？

Question

我正在创建一个应用程序，需要由内部网络上托管的Web前端访问，并且还可以作为计划任务运行。在我们的内部系统之外不需要访问任何内容，一旦应用程序启动并运行，我们就不会想到任何变化。

我最初的想法是创建一个封装大部分必要功能的DLL，然后通过Web Forms接口调用它来手动执行，并将控制台应用程序作为自动（每日）计划任务运行。

另一个建议是为核心功能公开Web服务，但由于应用程序永远不需要被外部资源调用，我认为实现Web服务所需的额外工作可能不值得麻烦。 DLL解决方案也应该快得多（？）。

我的问题是你会选择哪条路线？我有没有涉及的优点/缺点？有任何明显的遗漏吗？

免责声明：我是.Net的新手，但是由于我们的一位开发人员遇到了严重的事故，我被要求加入其中。

Answer 1

就个人而言，我说与DLL一起使用。它会快速而简单。

使用Web服务，您需要考虑您的网络，防火墙，性能等。它还使调试更加困难，因为您将无法从客户端进入Web服务，您将拥有在呼叫的两侧设置断点。

Web服务的另一个问题是您需要更加强大的处理故障。使用DLL，您知道对方法的调用将会成功，但是对于Web服务，您需要准备好在每次进行任何调用时该调用失败或超时。

最后，如果您在以后发现需要Web服务，那么您应该能够轻松地将DLL转换为Web服务，而且只需要进行最少的改造。

Answer 2

现在没有需要创建一个Web服务。您只需在服务器上维护其他IIS服务即可。如果您以后创建一些需要该DLL的接口，您可以简单地引用它。所以没有必要这样做预防。

Answer 3

你说得对，网络服务经验很麻烦，速度慢很多。 我建议 - 做一个PONO（普通的旧.net对象），但使用接口。查看Spring.NET框架 - 它可以为您导出此对象作为任何类型的（Web）服务，因此您不需要执行plumming。 在客户端，您还可以使用spring来执行依赖项注入，并通过更改配置文件中的值来决定是否需要进程内DLL或Web服务实现。 Spring也有Quartz调度程序集成，您可能也想查看它。

Answer 4

使用DLL是一种正确的方法，它更快，并且在将来通过使用这些dll（如果需要）创建webservice并提供更高的webservice安全性，提供了自由。

Answer 5

就个人而言，我会按照你所说的去做;把我的逻辑放在DLL中。然后使用您的应用程序中的DLL，Web服务以及将来要求确定的界面。

Answer 6

我们确实需要更多信息。知道你的要求是什么，很难回答。分层方法（dll /单独类）简单快速。分层方法（Web服务）将让您拥有一个环境并为您提供更多抽象。您无需更改客户端即可更改Web服务背后的代码。

但是为了评估这个，我们需要知道你的项目是什么，这个dll会做什么。否则你只是听到人们的偏好。

Answer 7

将逻辑封装到程序集中就足以满足您的解决方案，因为似乎没有任何东西会离开您的域的边界，您的内部应用程序将使用您设计的组件公开的功能。

为了可维护性，您可以非常轻松地从URL加载此程序集，如果需要将此组件包装到Web Service中，那么它肯定是可能的，然后您的代码可以创建Web代理类代码更改。

Answer 8

我正在开发一个类似的应用程序。我采取的方法是在dll中使用我的提取逻辑。这是通过Web服务公开的。我发现Web服务更简单，因为我不需要在客户端上删除接口或暴露我的对象（我使用类来封装数据）。然后我让Web开发人员和winforms开发人员编写自己的表示层。虽然有利有弊（不会进入他们），因为我只有一层，因此Web服务更简单。使用远程处理，我需要在每个客户端上安装额外的接口或客户端库。这样，我只管理服务器端，而不同的GUI是独立的。我喜欢松耦合编码。 我们运行许多Windows服务，也使用web服务。我们是一个信用卡组织，我们与众多系统进行互动。 Web服务使用最灵活。

毕竟，考虑到您的要求，它归结为您个人的偏好。我会说，如果不考虑以最小的努力进行更改的能力，就不要选择1而不是另一个。我发现rad应用程序可以根据不断增加的新要求快速更改。花点时间，考虑项目的范围和寿命以及需求。然后发展你的优势。

Answer 9

我无法相信接受的答案是建议您使用DLL的答案......

“我们不会设想任何改变一段时间。”

这就是为什么我们必须花时间解决开发人员做出这些决定所造成的问题。不要只考虑今天，想想明天。数据库的东西应该从客户端隐藏，如果你必须添加一个新的客户端，明天一个新的客户端？建立适当的合同和使用服务，网络与否。

Answer 10

哇哇哇哇。他们共用一个DB？如果是这样的话，不，不，不。如果数据库未共享，那么它肯定是DLL。

正确的选择是Web服务。原因很简单。

1）域模型和业务逻辑的一致性。假设您将枚举存储在列中，并添加枚举并部署到一个应用程序。它现在将打破其他两个应用程序。

2）易于部署。一个变化=一个部署。如果是dll，则一次更改= 3部署。

3）数据库事务和并发控制。在一个应用程序域中更容易解决它。

至于其他人提出的缺点，我觉得它们太偏了。

1）跨app域调试困难。您应该通过WSDL将可能的异常发布为故障异常。调用客户端也应该适当地处理这些错误异常。在呼叫客户端和服务器上设置单元测试和模拟也非常容易。断点不是调试和使用分布式应用程序的正确方法。你可以，而且并不困难。我只是不相信这是正确的方法。

2）表现。 WCF允许您通过配置设置不同的绑定。从基本的http（更易于调试）一直到命名管道，您可以使用它来获得近乎原生的呼叫性能。这个决定可以（差不多。有一些你需要考虑的不同约束的怪癖。）也要在开发后决定。

3）安全。说WCF无法处理安全性是非常错误的。

最后，我的真实缺点：

1）更复杂。同意。不同的环境使应用程序设计更加困难这有两种方式。这种复杂性迫使层级明确分离。演示文稿上下文应保持在演示级别。

2）需要更多计划。为WCF Web服务设计合同本身就是一门艺术。

3）配置的管理开销。对于新开发者来说可能是令人生畏的，但我希望你能快速克服这个障碍。 WCF配置是一把双刃剑，功能强大但复杂（对于某些人来说）。

我的个人经验是，无论何时共享数据库并且DLL在多个应用程序域中使用，我都很遗憾我没有足够多的时间来使用Web服务路径。

那你最后的决定是什么？已经四年了。