Web services 使用Web服务代替DLL

我想看看大家对最佳实践的共识是什么，或者只是在编写应用程序时保持清醒

对于本例，我有以下内容：

• [HttpHandler]
• ClientRender.ProcessRequest（…）
• ClientFactory.GetInnerInfo（…）
• Services.ServiceConnect.GetCampaignService（…）
• [Web服务]
• Campaign.GetInnerClient（…）
• [Web服务]
• DAL.GetInnerClient（…）
• EnterpriseLibrary.CreateDatabase（…）
• EnterpriseLibrary.GetStroedProcCommand（…）
• 企业图书馆执行者（…）
• DAL.PopulateClientCampaignFromReader（…）
• DAL.clientActivityFromDataReader（…）
• 返回呼叫树

问题:

我是什么类型的表演 通过调用Web服务引起的 从Web服务中从 在HttpHandler中

这不是更有意义吗 将其重写为程序集，而不是 超过2个Web服务？（并将 程序集顶部的Web服务 用于WSDL发布。）

我们也有一个管理网站 利用这些相同的组件和 “正确”添加需要2-3天 对一个数据进行简单的CRUD操作 实体。你赞成搬家吗 采取更直接的方法

---

希望这是有意义的，欢迎反馈。

当然，嵌套web服务调用的任何有效理由都不明显

---

这并不意味着没有理由，只是不明显。您可能应该询问编写服务的人。

我想这是对Web服务应该提供什么的误解。使用WS创建句柄数据库调用毫无意义。你可以：

为数据库抽象和业务逻辑构建单独的程序集。像“GetStoredProcCommand”这样的方法和类应该属于单个程序集，而业务逻辑应该属于另一个程序集或程序集组

将这些程序集用作Web服务的基础

在构建Web服务之前，必须坐下来了解谁将使用它，以及如何使用它。如果你不知道Web服务应该做什么，那么构建一堆Web服务是没有意义的。它最终会变得一团糟，因为在构建它之后，你会推掉真正的功能

如果您的Web服务应该从内部应用程序中使用，请记住，使用Web服务会对性能产生影响。如果您试图通过WS做所有事情，那么速度会很慢

---

到目前为止，我得到的唯一原因是允许最终构建一个公共API。对我来说，这似乎是答案。例如，公共API需要一致性，这是当前设计所没有的。你最终会得到很多漏洞百出的抽象。web服务“处理数据库调用”是没有意义的，但拥有一个内部web服务（不向公众公开）在“实体”级别处理数据是有意义的。通过这种方式，一组通用的业务实体可以暴露给任何需要它的内部软件，包括其他web服务。ADO.NET数据服务是这方面打包实现的一次尝试。因此，我们已经放弃了所有Web服务，我们将在以后的计划中创建真正的Web服务。现在，我们的大多数应用程序都在标准的DLLs+网站配置中工作。我们应该知道这个“示例”是什么意思吗？它更多的是伪代码，但它显示了一个WS调用WS调用WS的流程。对于来自旧web站点的简单调用，它将调用至少15个WS方法，包括WS中的整个DAL。如此多的HTTP开销不可能如此高效。。。