使用Web服务而不是DLL

Question

我希望看到对于最佳实践的共识是什么，或者只是在撰写应用程序时非常理智。

对于这个例子，我有以下内容：

• 的 [HttpHandler的]
• ClientRender.ProcessRequest（...）
• ClientFactory.GetInnerInfo（...）
• Services.ServiceConnect.GetCampaignService（...）
• [网络服务]
• Campaign.GetInnerClient（...）
• [网络服务]
• DAL.GetInnerClient（...）
• EnterpriseLibrary.CreateDatabase（...）
• EnterpriseLibrary.GetStroedProcCommand（...）
• EnterpriseLibrary.ExecuteReader（...）
• DAL.PopulateClientCampaignFromReader（...）
• DAL.ClientCampaignFromDataReader（...）
• 返回通话树......

问题：

1. 我会遇到什么样的表现 通过调用Web服务招致 来自Web服务 在HttpHandler中？
2. 对它来说没有意义 将其重写为装配而非 2 Web服务？ （然后把 装配顶部的Web服务 用于WSDL出版物。）
3. 我们还有一个管理网站 利用这些相同的组件和 “正确”添加需要2-3天 对一个数据进行简单的CRUD操作 实体。你会争取搬家吗？ 采取更直接的方法？

希望这是有道理的，欢迎提供反馈。

Answer 1

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

1. 为数据库抽象和业务逻辑构建单独的程序集。像“GetStoredProcCommand”这样的方法和类应该属于单个程序集，业务逻辑应该属于另一个程序集或程序集组。
2. 使用这些程序集作为WebServices的基础。
3. 在构建WebService之前，必须坐下来知道谁将使用它，以及如何使用它。如果你不知道它应该做什么，那么构建一堆WebServices是没有意义的。它最终会变得一团糟，因为你在构建之后会推翻真正的功能。
4. 如果您的Web服务应该从内部应用程序中使用，请记住使用Web服务会对性能产生影响。如果你试图通过WS做一切，那就会很慢。

Answer 2

毫无疑问，嵌套Web服务调用的任何正当理由都不明显。

这并不意味着 没有理由，只是它不明显。你应该问那些写这项服务的人。

Answer 3

All your base are belong to the Architecture Astronauts。