I am familiar with web method. Now I got a suggestion to use web API instead of web method. I had done a demo of ASP.NET web API it's more closer to a MVC architecture am using the classical asp.net web development. I don't like to mess up the controller (MVC concept) with classical development.
我熟悉web方法。现在我有一个建议使用Web API而不是web方法。我已经完成了ASP.NET Web API的演示,它使用经典的asp.net web开发更接近MVC架构。我不喜欢用经典开发搞砸控制器(MVC概念)。
My web Method :
我的网站方法:
[WebMethod]
public static string GetName(int id)
{
return "testName";
}
My Web API controller:
我的Web API控制器:
public class MyController : ApiController
{
[HttpGet]
public string GetName(int id)
{
return "testName";
}
}
am really confused on this issue any one have a better idea on the same.
我真的很困惑这个问题,任何一个人都有更好的想法。
What is your suggestion on the same which is the better option?
对于同样哪个更好的选择,你有什么建议?
How can i compare, if both having same piece of code?
如果两个代码都相同,我怎么比较?
2 个解决方案
#1
14
The classic ASP.NET WebServices (what you call WebMethod) are a deprecated technology. There is no longer any active development. The ASP.NET Web API is a complete rewrite of the web stack from Microsoft in which you have far greater control for creating RESTful web services. This doesn't mean that you should choose between one or the other. There's also ServiceStack. If you are starting a new project you should stay away from classic webservices. If they are still present in the .NET framework it is for compatibility reasons with legacy code.
经典的ASP.NET WebServices(您称之为WebMethod)是一种不推荐使用的技术。不再有任何积极的发展。 ASP.NET Web API完全重写了Microsoft的Web堆栈,您可以更好地控制创建RESTful Web服务。这并不意味着您应该在一个或另一个之间进行选择。还有ServiceStack。如果您要开始一个新项目,您应该远离经典的Web服务。如果它们仍然存在于.NET框架中,则出于与遗留代码的兼容性原因。
#2
3
Complementing Darin's answer, if you want to test your method from ApiController, you can inject the object's dependencies using an DI container (http://www.asp.net/web-api/overview/extensibility/using-the-web-api-dependency-resolver). The dependency injection is done automatically.
补充Darin的答案,如果你想从ApiController测试你的方法,你可以使用DI容器注入对象的依赖项(http://www.asp.net/web-api/overview/extensibility/using-the-web-api -dependency-分解器)。依赖注入是自动完成的。
However, with webmethods, you can't use DI in that way because webmethods must be static. If you insist in using DI, you need to instantiate and call the container directly in each of the webmethods to get the dependencies to work on.
但是,使用web方法,您不能以这种方式使用DI,因为web方法必须是静态的。如果您坚持使用DI,则需要在每个web方法中直接实例化并调用容器,以使依赖项工作。
#1
14
The classic ASP.NET WebServices (what you call WebMethod) are a deprecated technology. There is no longer any active development. The ASP.NET Web API is a complete rewrite of the web stack from Microsoft in which you have far greater control for creating RESTful web services. This doesn't mean that you should choose between one or the other. There's also ServiceStack. If you are starting a new project you should stay away from classic webservices. If they are still present in the .NET framework it is for compatibility reasons with legacy code.
经典的ASP.NET WebServices(您称之为WebMethod)是一种不推荐使用的技术。不再有任何积极的发展。 ASP.NET Web API完全重写了Microsoft的Web堆栈,您可以更好地控制创建RESTful Web服务。这并不意味着您应该在一个或另一个之间进行选择。还有ServiceStack。如果您要开始一个新项目,您应该远离经典的Web服务。如果它们仍然存在于.NET框架中,则出于与遗留代码的兼容性原因。
#2
3
Complementing Darin's answer, if you want to test your method from ApiController, you can inject the object's dependencies using an DI container (http://www.asp.net/web-api/overview/extensibility/using-the-web-api-dependency-resolver). The dependency injection is done automatically.
补充Darin的答案,如果你想从ApiController测试你的方法,你可以使用DI容器注入对象的依赖项(http://www.asp.net/web-api/overview/extensibility/using-the-web-api -dependency-分解器)。依赖注入是自动完成的。
However, with webmethods, you can't use DI in that way because webmethods must be static. If you insist in using DI, you need to instantiate and call the container directly in each of the webmethods to get the dependencies to work on.
但是,使用web方法,您不能以这种方式使用DI,因为web方法必须是静态的。如果您坚持使用DI,则需要在每个web方法中直接实例化并调用容器,以使依赖项工作。