使 .NET Web 服务可以在本地和远程访问？
假设我正在构建两个应用程序：
1）公共网站
2）服务
当然，用户可以访问该网站。
该服务可以通过 Web API 使用，但也可以由网站使用。
这意味着通用功能只能放入服务中，而不是在网站和服务中重复使用。
现在，在部署此解决方案时，似乎有两个选择：
1）让网站直接引用 Web 服务，并将两个二进制文件部署到 Web 服务器，在同一进程中运行。
2) 让网站通过 Web API 引用 Web 服务，就像所有其他消费者一样。让服务在单独的进程中运行。
选项 1 的性能可能会更快，但需要单独部署两个 DLL。
有什么方法可以选择选项 2（单独的进程），但仍将网站直接链接到服务，以避免网络延迟、序列化等？
Say I'm building two applications:
1) A public website
2) A service
The website can be accessed, of course, by users.
The service can be consumed through a web API, but will also be consumed by the website.
This means that common functionality can be put in the service only, rather than having it duplicated in both the website and the service.
Now, when deploying this solution, there seem to be two options:
1) Have the website directly reference the web-service, and deploy both binaries to the web-server, running in the same process.
2) Have the website reference the web-service through the web API, just like all the other consumers. Have the service run in a separate process.
Option 1 would probably be faster for performance, but would require having the two DLLs deployed separately.
Is there any way I can have option 2 (separate processes) but still link the Website to the Service directly, to avoid network latency, serialization, etc?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您的网络服务使用什么技术？如果您使用 WCF，则可以为您的网站使用 NetNamedPipeBinding，这几乎与直接使用 dll 一样快。
What technology are you using for your web service? If you're using WCF you can use the NetNamedPipeBinding for your website which is almost as quick as using a dll directly.