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?
Related
Our project is using multitenancy to resolve some Service, lets say MyService based on SaasKit.
We also have a background task, which shares some of it's dependencies with the asp.net core controllers.
In the background task, any object that depends on MyService will get a null reference.
I can implement workarounds to get instances of MyService, like using service locator pattern, but this approach fails to create classes that depend on MyService without breaking DI and IOC logic.
So the question is: How can I get the same services that I can get from HttpContext with multitenancy, but get them without an HttpCoontext?
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.
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 have a solution with an MVC application and a Web API. They're in separate projects and domains (using CORS). I built it as a Web API to have the flexibility for adding consumers but currently my MVC application is the only consumer. As such I'm debating whether to use HttpClient inside my MVC Controller or directly instantiate the ApiController.
In either case, I'm using dependency injection (Autofac) so I'd also like to know how to configure that because neither HttpClient or ApiController have any kind of interface that I can inject through constructor parameters like I usually do so I'm not sure how to handle this.
What should the lifetime scopes be for the injected instance? HttpClient should probably be Singleton since it's not encouraged to dispose it after each request.
NOTE By calls to the API return large datasets used to populate charts which is why I'm leaning a bit away from HttpClient as I feel I will incur additional overhead using Http. Is it an antipattern to directly instantiate the ApiController?
Thanks
You could always do this
var httpClient = new HttpClient(new HttpServer(GlobalConfiguration.Configuration));
This allows you to continue using the HttpClient but the requests get passed directly to the WebApi server without ever making a network request. This way if you later decide to separate out your WebAPI your client code doesn't change
I recently created a WCF service library. I am planning on hosting it in IIS. Since I want to reuse my repository layer I decided to go use Ninject in my WCF service as well (I use it in other projects in the solution).
I installed the Ninject Wcf Extensions. I configured it using the NinjectServiceHostFactory in the svc file. I added a Global.asax file to override the CreateKernel() that inherits from NinjectWcfApplication but I am not sure if I am using the bindings correctly. I first started with:
Bind<IUnitOfWork>().To<UnitOfWork>().InRequestScope();
But I quickly realized that this does not work since no data was saved to my database. It appears that the WCF service does not use the ASP.NET pipeline. I went ahead and tried both of these as well just to see if my data was committed to the database:
Bind<IUnitOfWork>().To<UnitOfWork>().InThreadScope();
Bind<IUnitOfWork>().To<UnitOfWork>().InTransientScope();
No luck. I then decided to try:
Bind<IUnitOfWork>().To<UnitOfWork>().InSingletonScope();
This worked but I don't want my database context to be shared by every single request that comes in to the WCF service. I then did some research and found the following approach:
Bind<IUnitOfWork>().To<UnitOfWork>().InScope(c => OperationContext.Current);
This works but is it correct? I wan t something to resemble the InRequestScope for a MVC application. Each request to the service should get its own Database context.
I suggest to have a look at the latest build from the CI-Server http://teamcity.codebetter.com
You need Ninject, Ninject.Web.Common, Ninject.Extensions.Wcf
With this version you can use InRequestScope for Wcf.
I am new to Ninject, but I can tell you that OperationContext.Current is the equivalent to HttpContext.Current for web application.
So your first thought was to use .InRequestScope(); (which is equivalent to .InScope(c => HttpContext.Current);)
so I guess that using .InScope(c => OperationContext.Current); for WCF is pretty correct.