如何通过网络启用 .NET 库
我希望将现有的 .NET 库公开到 Intranet。
随着许多人转向 RESTful 服务，OpenRasta 看起来很诱人。 以类似的方式，我正在玩 Sinatra in IronRuby。
我主要寻找三点：
1) 您使用什么来将现有的代码库公开到网络上？
2）你的方法如何使其易于实现
3）你的方法如何确保其安全？
I am looking to expose my existing .NET libraries to an intranet.
With many moving to RESTful services, OpenRasta looks tempting.
In a similar vein, I am playing around with Sinatra in IronRuby.
I am primarily looking for 3 points:
1) What are you using to expose your existing codebase to the web?
2) What about your method makes it easy to implement
3) What about your method makes it secure?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为，如果您的图书馆并非设计为暴露于互联网，那么这样做是一个坏主意。
此外，如果您的库不处理在 HTTP 意义上作为资源有意义的事物，那么使用 REST 接口公开它们并不是一个好主意。
回应评论“为什么？”
我假设它是一个设计良好的库。 我假设您在设计库时考虑到了某些要求； 某些用例和场景； 您甚至可能编写了使用该库的示例，只是为了确保它易于使用。 结果，这个库满足了所有这些要求，可以说是精心设计的。
但您似乎没有在您的要求或用例中包含“暴露于互联网”。 您似乎也没有包含“通过 REST 接口公开”。 很可能，经过精心设计以满足一组要求的库将无法精心设计来满足其他两组要求，除非是偶然的。
对于 REST 方面尤其如此。 库公开的对象不太可能满足 REST 所基于的“资源”的 HTTP 定义。 试图将它们扭转成正确的形状只会很痛苦。
我的建议是收集一组新的需求，将您的库的功能作为一组精心设计的服务公开。 这些服务将通过调用您的图书馆来实现。
在理想情况下，此过程将生成一个与您一开始设计的 REST API 完全相同的 REST API。 但它可能会导致完全不同的结果。
I think that if your library was not designed to be exposed to the Internet, then doing so is a bad idea.
Further, if your library doesn't deal with things that make sense as resources in an HTTP sense, then it's not a good idea to expose them with a REST interface.
In response to the comment, "Why?"
I'll assume it's a well-designed library. I assume you had certain requirements in mind when the library was designed; certain use cases and scenarios; you may even have written samples of using the library, just to make sure that it was easy to use. As a result, the library met all of these requirements, and can be called well-designed.
But you don't seem to have included "expose to the Internet" in your requirements, or use cases. You don't seem to have included "expose via a REST interface", either. Chances are that the library that is well-designed to meet one set of requirements will not be well-designed to meet the other two, unless it's by accident.
This is especially the case for the REST aspect. The objects exposed by a library are quite unlikely to meet the HTTP definition of "resource" that REST is based on. Attempting to twist them into the right shape will just be painful.
My recommendation would be to get a new set of requirements together for exposing the functionality of your library as a well-designed set of services. These services would be implemented by calls to your library.
In an ideal world, this process would result in a REST API that is exactly like the one you would have designed in the first place. But it may result in something quite different.
我个人使用 WCF 来公开我的 .NET 库。 它支持许多不同的传输协议和绑定。 我相信您会找到适合您需求的一款。 它还允许您实施安全通信。
Personally I use WCF to expose my .NET libraries. It supports many different transport protocols and bindings. I am sure you will find the one that fits your needs. It also allows you to implement secure communication.