There is a sales service implemented as a Telegram bot. I need to create a website control panel for this service. Since the service is a .NET application I am thinking to use ASP.NET Core technology.
How do I transfer data from the controller action to the Program class containing all the functionality of the service (maybe it is worth defining the Program as a static class)?
You may have misunderstood Asp.Net Core. .net core adopts the pipeline mode, that is, when you call the action in the controller, it will enter the middleware pipeline of Program.cs(.net 5 is Startup.cs), and execute in sequence according to the order of your middleware, adopting the principle of first in, last out. This means that if you follow the normal .net core logic, the value you get in the controller (except the parameters defined in the URL), you cannot pass it into Program.cs. When you successfully enter the action of the controller, Program.cs has been executed.
Not sure what your sales service looks like, but I think you can register it as a service and use it in your controllers using dependency injection.
Helpful link: ASP.NET Core Middleware.
Related
My team maintains a very large .Net Core 2.1 web site. Lots of controllers, lots of services that get injected into the controllers via constructor injection.
Sometimes due to developer error a service class is no longer added to the DI container during startup. Obviously this leads to an exception when MVC tries to construct a controller that relies on that service (in response to an incoming request).
Problem is that this may affect only some lightly used controller, so our (far from perfect) regression testing doesn't pick up the regression bug. But it is still bound to be picked up by one of our (very demanding) customers.
I though of writing a unit test that would
Instantiate a ServiceCollection class (that implements IServiceCollection);
Call our own method that adds all services to that service collection (the same method used during normal startup);
Find all controllers through reflection, and try to construct them the same way MVC does - by getting dependent services from the DI container.
So my question is:
Does this approach make sense?
Is there an example somewhere that I could use?
Failing an example, how would I achieve 1) and 3) ?
Now i have asp mvc 5 .net framework project and handlers (ashx files with custom logic) to process customer needs (i.e. pricelists in custom format).
I intend to move to asp core, and the question : is there an equivalent to handler?
Articles on internet suggest to put logic to middleware, but this is inconvenient way in my case.
Can you explain what do you need that middlewares cannot provide them for you?
Middlewares are built in a way that you can completely migrate from old Http Handlers/Modules to them.
https://learn.microsoft.com/en-us/aspnet/core/migration/http-modules?view=aspnetcore-2.1
Razor pages with it's own logic and model best way to substitute custom handlers in my case
You could use Middleware or Interceptor for tracking any incoming request.
The most important difference between them is that, you could use interceptor per any action too - for this you should use dependency injection.
I am using ASP.Net core and I have a requirement to access a specific HTTP Header in a business logic class (not a controller or action).
To provide a full picture of the configuration here, I have a custom ASP.Net Core Middleware which based on some logic will add a value into a custom HTTP Header, it is the value from this header that I need to access in the business logic class.
Currently the way that I achieve this is to inject an HttpContextAccessor, using the following DI registration.
services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
In the class which requires access to the HTTP Headers I then request an IHttpContextAccessor using constructor injection and use this to access the relevant HTTP Header.
Doing the above works fine and gives me the results that I require, looking around various articles on the Internet however the general consensus appears to be to avoid using HttpContext.Current in ASP.Net Core.
If the above is the case, is there a better way for my business logic class to access the value that my custom middleware is inserting into a custom HTTP Header?
I should be clear, whilst at present the middleware is storing the required value in a HTTP Header for use by the business logic class, I am open to other methods of the middleware making the required value available to the business logic class if there is a better approach.
Any questions or clarifications, please let me know.
There is no HttpContext.Current in ASP.Net Core, so it's easy to avoid using it. You would have to implement your own extension method if you wanted it, but the general feeling in the .Net Core community is that it's much better to use IHttpContextAccessor.
In earlier versions of .Net Core an implementation of IHttpContextAccessor was auto registered in the DI container. In more current version you have to register it yourself with the line of code you mentioned:
services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
Injecting IHttpContext into your method that needs access to the headers is a workable approach. Or if you like you could use a helper method that places a copy of the headers in a simpler structure and then pass that object in to your class since it doesn't really need access to the full HttpContext.
I have a custom authorization attribute, required only for some actions, which checks the request headers for a custom token. The token is checked in a database. Checking the database requires access to a service which I would like to have injected through the constructor.
The way I have read this can be done (here, here, and here) is by having a constructor-less filter and injecting the dependent one like this:
kernel.BindFilter<MyAuthorizeFilter>(FilterScope.Controller, 0).WhenControllerHas<MyAuthorizeAttribute>();
However the BindFilter method is not available to me as I have setup Ninject as described here. This is using Ninject.Web.Common instead of Ninject MVC3 as I read that Ninject MVC3 would not work with MVC4 RC. How else can I go about accomplishing this?
I have read also that I could add to GlobalFilters.Filters - however I don't want it to be present on every action.
Thanks in advance for any answers.
I'm not completely sure I see how you have set up your application, but my experience has been that if you want a filter for a WebApi controller you need to add it to the HttpFilterCollection that is available from the GlobalConfiguration.Filters. This is a Different set of filters than what MVC uses (through the GlobalFilterCollection).
I’m aware that not everyone uses a thorough architecture when developing an MVC application but let’s assume I have the following architecture:
App.Core --> Class Library (POCO or Domain objects)
App.Data --> Class Library (Repository and Entity Framework)
App.Service --> Class Library (Service layer with all business logic)
App.Web --> asp.net MVC 3.0 project
App.Data --> Has a reference to App.Core
App.Service --> Has a reference to App.Core and App.Data
App.Web --> Has a reference to App.Core and App.Service
Inside our MVC application we try to follows this approach:
Inside our Controller (within a method), we instantiate a ViewModel.
We fill that ViewModel calling methods from our App.Service Layer
Once the ViewModel is filled, we return it to the View (so the view
is now strongly typed).
This occurs 99.9% of the time. It is clean, we like it and it leverages itself pretty well..etc!
Now my question is the following:
If we decide to move our application to MVC 4.0 and start using the
new Web API approach, I’m not sure I fully understand where (or how)
it would fit in our current architecture?
Keep in mind, that we are open to change this around!
Should we create a new App.WebAPI layer that sits between the App.Service and App.Web?
This means inside our Controllers, we would no longer need to call the App.Service directly but instead the new App.WebAPI layer?
Or, leave the Web API inside the App.Web layer and make the Controllers call the other APIControllers which in turn would call the App.Service layer?
Not sure if I make any sense here…but please feel free to suggest anything as I’m curious on different inputs.
Thanks
There are a couple of cases to consider:
Do you want to make this Web API serve as service layer and data access for your MVC application? If, yes, then you should completely remove all references of App.Service from the ASP.NET MVC project and have it query the Web API instead to fetch the data. In this case the Web API sits between your ASP.NET MVC application and the data access. It is the Web API that talks to the service layer and exposes it over the HTTP protocol.
Or do you want to provide an additional API for your web site that can be used by other clients (other than web browsers)? In this case the ASP.NET MVC application and the Web API sit on the same layer. Both query your Service layer to fill view models, it's just that in the case of the MVC application you are passing those view models to views which in turn convert them to HTML whereas in the Web API layer you probably use slightly different view models but which are still populated from your service layer and are passed to the client used the corresponding serialization mechanism (JSON, XML, ...)
I know this is late but I was actually looking for the same advice and I found this post.
Wouldn't having "both the MVC and Web API sit within the same layer" mean more maintenance work on the code, or maybe duplication of code? isn't the mvc web considered as a browser client? .. to me it makes sense to have the WebAPI your only layer to everyone else and in turn it would call your service layer for processing.
What is the benefit of leaving both the Web API and the MVC talking directly to the service layer? Can't the web API be the wrapper around the service layer?