I'm very new to Asp.Net Web Apis(which Microsoft has made a part of MVC templates though we can use Web Api template independent of MVC)....Just a little background.
Coming back to my problem when my Web Service is called by a user then along the line of what my Web Service is serving comes a point where I have to deserialize a Json file to a generic C# collection and cache it in-memory and then the code inside one of the Controller actions(which is obviously a get method) checks for the in-memory cache and if it has that deserialized C# collection it gets it from there else its calls another method inside the controller which caches this generic collection in memory.
My question is ...is this possible to cache the stuff for a Web Api like what I described above...I'm quite familiar with Asp.Net page life cycle,caching and sessions etc. But not with Web Api....And my above explanation is just an abstract idea...not sure how to execute it, will it work? If yes then what namespaces would come in handy like System.Runtime.Caching or System.Web.Caching.
Your answers will be highly appreciated....
In the .NET Framework 3.5 and earlier versions, ASP.NET provided an in-memory cache implementation in the System.Web.Caching namespace. In previous versions of the .NET Framework, caching was available only in the System.Web namespace and therefore required a dependency on ASP.NET classes. In the .NET Framework 4, the System.Runtime.Caching namespace contains APIs that are designed for both Web and non-Web applications. ASP.NET Web API doesn't have dependency in System.Web.dll so I recommend you to using System.Runtime.Caching, you can put your caching logic anywhere even in separate .dll file and use it in your ASP.NET Web API project.
Related
I'm converting all of our shared class libraries from .NET Framework to .NET Standard so that they're consumable by both our older .NET Framework and our new .NET Core applications. The goal is to get all of our applications to .NET Core, but it's a large system so will take time so we need the two worlds to coexist for a year or so in the meantime.
One of the pain points is that the shared class library code leverages HttpContext extensively. I understand that the new .NET Core way to access it from within class libraries is to use AddHttpContextAccessor. However, we still have old ASP.NET web forms applications AND new ASP.NET Core web applications that both need to call this common code. If I switch to using HttpContextAccessor with DI then it won't work from the old ASP.NET Web Forms app, as it has no concept of what HttpContextAccessor is.
I'm wondering what my options are here... Is there a way to set up access of HttpContext such that it can be consumable both in ASP.NET Web Forms and ASP.NET Core?
You have to have some common interface between both the old and new applications I would think.
Create a new IMyHttpContext and inject that type into both the old and the new. Use your DI infrastructure to instantiate a new MyClassForOld: IMyHttpContext that accesses an underlying reference HttpContext for the old apps and use your DI to instantiate another new MyClassForNew: IMyHttpContent that accesses an underlying reference to HttpContextAccessor
I have a set of 7 .Net Framework WebApi-based services that all share some common design elements. One shared element is that each will include the service version in the data that it returns from any of its endpoints. In each service, I determine the version from the executing assembly using reflection. I do this in Application_Start and store the result in a property that I create on the Global class that inherits from System.Web.HttpApplication. That way I do the reflection work once and access the result later from each of my methods.
I'm building a new service and this one is built on ASP.NET Core. So I'm trying to figure out how to do the same thing in ASP.NET Core. I can add the reflection logic in Startup.Configure (though it's not really about configuring the Http pipeline which is what Configure is supposed to be doing). Is there a better place than Startup.ConfigureServices or Startup.Configure, to put code that you want to run once on startup?
And where would I store the result to make it readily accessible to each of the downstream methods called from my controller actions?
i need few reason for which people mixed ASP.Net MVC and web-api in same project. when we can develop a full project in mvc only then why web api need to include. also we can host webapi project separately which can server request to MVC and other devs or mobile devs etc.discuss the reason and advantages.
some one answer :
We have recently built a project within MVC and WebApi, we used the WebApi purely because from a Mobile Apps perspective. We allowed the mobile dev guys to call our methods within our MVC application instead of them having to go and create the same function.
WebApi allows to create services that can be exposed over HTTP rather than through a formal service such as WCF or SOAP. Another difference is in the way how WebApi uses Http protocol and makes it truly First class Http citizen.
still the above answer is not clear to me and i think this is not the reason for which people mixed ASP.Net MVC and web-api in same project.
so anyone mind to discuss the actual reason and advantages with example scenario.
thanks
Each have a purpose. Most of the time it's usually caused by legacy code. I know we included documentation which used MVC, but we're fully webapi.
FYI, was MS's auto documentation for WebApi ironically.
I have a web application that is developed using ASP.NET MVC.
The application follows the nth-tier architecture, and I have divided the application into 4 different project which are Model, Core, Framework and the web application.
The Model, Core and Framework are DLLs, the Model contains just my POCO classes, the Core contains my DbContext, repositories and Unit of Work implementations while my framework project contains classes that would be used directly by my MVC web application such as action-link extension, custom view engines e.t.c.
In addition to my framework I created a class called service which makes method calls to the repositories in my core DLL and method in the service class are called by my web application.
My question is: Is it ideal to channel method calls from the web application to the repository through my the service class in my framework DLL or just make a direct call to the Core DLLs?
Don't add an abstraction layer unless you require it. If you don't have a strong reason to add a service layer in the middle, you will end up implementing the Poltergeist anti-pattern, where sole purpose is to pass information to another object.
In general, calling your repository directly is perfectly fine so you have to analyze if you foresee any particular restriction disallowing this schema.
I am considering building some services using the new Web API that's introduced in ASP.NET MVC 4 (currently in beta version). I am quite clear on the way these services can be invoked using REST which returns responses either in JSON or xml.
However is there a way where I can add these services reference in client application and generate stubs for response objects, similar to the way .NET response objects are created when we add a WSDL reference.
ASP.NET Web API does not have any such built in capability. Short of providing some WSDL-like metadata information that the existing VS tooling could read VS 2010 does not have a way to create a CLR object from a JSON service.
However, another approach you could consider is to create a simple class library with the DTO (data transfer objects) classes that could be used by both the server and the client.