Web 服务与 DLL；优点和缺点？
我正在为我们的网站实施一项网络服务，该服务通过互联网请求并接收来自第三方的数据。我还被要求创建一个 DLL，为内部 Windows 应用程序复制 Web 服务的功能。
我的问题是；不创建 DLL 并使用 WEB 服务用于内部和 Web 应用程序有哪些优点/缺点？
从维护的角度来看，我更愿意支持单一服务。想法或想法？
I am implementing a web service for our website which requests and receives data from a third party via the internet. I have also been asked to create a DLL duplicating the functionality of the web service for an internal windows application.
My question is; what are the advantages/disadvantages of NOT creating the DLL and using the WEB Service for both internal and web applications?
From a maintenance point of view I would prefer to support a single service. Thoughts or ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
创建 WCF 服务。 Windows应用程序可以直接访问dll中的服务类，而WCF将其公开为Web服务。您只需以这种方式编写和维护一段代码即可。
Create a WCF Service. The Windows application can access the service class in the dll directly, while WCF exposes it as a web service. You just have to write and maintain one piece of code that way.
在我看来，您应该将此逻辑创建为类似 WCF 服务的东西，可以以多种格式托管。接口优先的开发策略仍然允许您通过直接实例化服务来将其用作内存中的类，但您也可以使用带有代理的“共享内存”端点来轻松地在使用服务之间移动Web 边界与共享内存与 TCP/IP。
托管模型可以是 IIS，并使用 basicHttp 绑定，其外观和行为与传统的 WebService 非常相似，但也可以托管在 Windows 服务、Windows 窗体应用程序甚至 ConsoleHost 应用程序中。
In my opinion you should create this logic as something like a WCF-Service which can be hosted in a variety of formats. The interface-first development strategy would still allow you to use the service as nothing more than an in-memory class by directly instantiating it, but you could also use the "shared memory" endpoint with a proxy to easily move between consuming the service across a web boundary versus shared memory versus TCP/IP.
The hosting model could be IIS and use the basicHttp binding to look and act very much like a traditional WebService, but could also be hosted within Windows Service, or Windows Forms application or even a ConsoleHost application..