使用服务而不是组件有什么优缺点？

Question

从过去的几个月开始，我正在研究最新的dot net框架中的项目。

我觉得在最新的dot net版本中，鼓励“服务”而不是组件。这是对的吗？

我在银光中看到过（我是银光的初学者）所有数据库层操作都作为服务公开。我现在还不知道组件程序是否可用？

有什么好处？如果所有层都作为服务而不是DLLS公开，那么性能如何？

请通过一些关于这个主题的说明，我应该从哪里开始正确理解这个概念？

由于

SC

Answer 1

这真的与面向服务的体系结构有关 - 这种情况在很长一段时间内很常见，而且很受欢迎。

这个想法是不同的操作彼此分离，因此可以重用和修改它们，而无需重新编译使用它的应用程序。而不是在DLL中的一段代码被修改和复制到任何地方，可以部署一个服务，代表特定处理或信息源的单一访问点。

假设您有信用卡验证组件。您可以编写此代码并将其编译为DLL并开始在所有应用程序中包含该代码。除非您发现错误或CC验证规则发生变化，否则没有错。或者您可能希望将其升级以针对黑名单进行检查。如果不重新编译使用它的应用程序，则无法执行任何操作。

但是，如果您的信用卡验证作为服务公开，则可以进行更改并部署到一个位置。如果签名相同（相同的参数和响应），应用程序甚至不必知道它已被更改。

使用服务而不是组件的另一个优点是服务可以托管在任何地方。它们可以位于本地服务器上，也可以位于世界的另一端。

说完这些之后，就像你应该根据具体情况决定架构一样。虽然信用卡验证是服务有用的一个很好的例子，但提供呈现HTML控件的服务并没有多大意义。

Answer 2

需要考虑的其他因素 - 仅仅因为功能作为“服务”公开并不意味着它必须在某个地方托管或作为Web服务公开。

您可以直接在内存中访问服务。

将相关功能公开为服务更多的是关于应用程序各个部分之间的交互。它没有说明如何部署/访问这些部分。

Answer 3

“跨语言”兼容性是另一个优势。您可以在C＃.net中编写服务，也可以从Java访问。因此，重用不仅仅是编程语言的使用。

  

有什么好处？关于   如果所有图层都是性能   作为服务而不是DLLS公开？

我会在这里注意这一点。 “所有图层”是什么意思？业务和数据访问层等应用层？我怀疑这可能有用（当然这取决于你的上下文）但通常服务是可以在许多不同的上下文中重用的东西。示例可以是用于验证财务代码的服务。然后，您将从应用程序的业务层调用此服务。我无法想象您将业务层公开为单独的服务而将数据访问层公开为另一个独立服务的情况。通常它们非常适合您正在开发的应用程序。可能的是，您有一个应用程序，例如可以通过Web访问（作为Web应用程序），并且还有另一个通过其他应用程序可以使用的Web服务的入口点（某种API）。这是有道理的，但是你不会直接暴露你的业务层，而是创建某种“网关”，这是你的webservice（一个委托给你的业务逻辑类的轻量级外观）。