Is it possible to call WebAPI endpoints without extending the Controller base class? I have a background service (base class HostedService implementing IHostedService) in .Net Core. My class structure is already set in stone so I can't change the base class of my background services. But it would be a huge help if I could call url endpoints on them without actually having a separate controller.
Is this possible?
EDIT: My background services look exactly like this.
Why don't you use something similar to ValuesController in the link you provided?
You only have to create a new Controller with almost any logic, just calls to your Hosted service.
Related
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.
I'm trying to build an asp.net mvc 4 application.
I want the application to encompass both a HTML site and a restful api, e.g.
www.mysite.com/MyDetails/
www.mysiste.com/api/users/{userid}/Details/
In the above example I would use 2 controller classes.
MyDetailsController which inherits from System.Web.Mvc.Controller
DetailsController which inherits from System.Web.Http.ApiController
I've also added a simple 'Users Route' to the WebApiConfig:
routeTemplate: "api/users/{userid}/{controller}/{id}
In my early testing it appears as though the following scenarios are invalid:
www.mysite.com/api/users/12345/MyDetails/
www.mysite.com/Details/
Both of those return a 404.
This is definitely a good thing but what I'm trying to find out is why doesn't it work?
Can I rely on it not working or is it just coincidence in my simple test?
I've read about people struggling to develop a single MVC app/project that encompasses both HTML and REST apis but the most common complaint seems to be you can't duplicate controller names and it still seems like you can't simply use a namespace to differentiate them.
In this example I've deliberately designed the class names to avoid any conflict so what other gotchas are waiting to trip me up?
Thanks,
Chris A
Check your routes file, should be Global.asax under RegisterRoutes. The MapRoute call should tell you everything you need to know for MVC routing. Keep in mind, the order of the routes is important: top routes take priority over the bottom. Web API uses the WebApiConfig class and MapHttpRoute call to configure routes.
Please ensure you have put a (MVC) route on top of the action you wish to hit of your controller, default action being index.
[System.Web.Mvc.Route("Help")]
public ActionResult Index()
{
ViewBag.DocumentationProvider = Configuration.Services.GetDocumentationProvider();
return View(Configuration.Services.GetApiExplorer().ApiDescriptions);
}
Code above will hit this action method (provided your controller is registered and derived either from apiController or Controller) in the following way:
http://localhost:54541/help inside your IISExpress.
To register please do the following:
In "global.asax.cs", you’ll need to add:
AreaRegistration.RegisterAllAreas();
I have started working on an application which is structured as follows:
UI - ASP.Net MVC web application
Service Layer - WCF
Entities - a simple class library (exposed by WCF layer)
Data Layer - for database interactions.
Till now, I was defining my models in Models folder of my web application, but now as we have decided to expose them by WCF service (as this application will be consumed by other applications as well), I need some help here.
I tried putting all my model definitions in Entity layer which is exposed by WCF service decorating them with data annotations as well as DataContract attributes. Now, I am able to reference these entities to bind them with my views. But, data annotation validations are not working for me.
Can anybody please help me for a workaround for this ? I have been searching through web for solution but almost all tell me to put a reference of entity layer in web application which will be tight coupling that we do not want. and the other option is to redefine all entities with data annotations in models folder of my web application,which will be duplicate kind of coding.
Is there any better approach for this? Any help appreciated.
Update:
To consume WCF entities, I have put a service reference in my web application. Now, just to check I modified that Reference.cs file by decorating my data Member explicitly with [Required] attribute and it is working fine. but, I understand these changes will go away whenever service code is generated.
Is there any way I can bring that Data annotation attribute here? Kindly help.
As for me It's bad idea, DTO for transfer, Model for MVC.
Look like similar problem
Why You Shouldn’t Expose Your Entities Through Your Services
DTO’s Should Transfer Data, Not Entities
Is HttpContext.Items still considered a reasonable place to share things between different parts of a request? Particularly HttpHandler's outside of MVC, like WIF extensibility points.
How do you access this dictionary from within MVC4's ApiController? Without using HttpContext.Current static methods (I still want it unit testable). The normal controller had HttpContextBase/Wrapper which abstracted it a bit for testing.
Use Request.Properties inside the Web API Controller.
When implementing an ActionFilterAttribute it's filterContext.Request.Properties
I am not understanding how my model can be a WCF service. It makes sense when its an Astoria partial class residing on the client that allows remote calls to do persistence calls, but a WCF service doesn't have properties for model fields that can be used to update a data store.
Even if I could factor out an interface for a model/domain object class into a separate assembly, a silverlight project will not allow me to add that as a reference.
How should my ViewModel encompass my WCF calls? Ultimately the WCF will call a repository assembly implemented in Linq-to-Sql, but apparently those entities are not my model in this scenario, my WCF classes are?
Thanks for any guidance on this.
Also, posts I have read to give a frame of reference:
http://development-guides.silverbaylabs.org/Video/Silverlight-Prism#videolocation_0
http://blogs.conchango.com/davidwynne/archive/2008/12/15/silverlight-and-the-view-viewmodel-pattern.aspx
http://msdn.microsoft.com/en-us/magazine/dd458800.aspx
When you create a service reference to a WCF service in a Silverlight project it also generates an interface for that Service, this is similar to David Wynns IFeedService in the articles you listed above. The service reference will also generate proxy objects that represent the objects used by the service (Product, Category etc).
The important thing to note is that the service interface isn't the model, it's how you access the model. Going back to David's example, his ViewModel exposes a list of items (his model), this list is retrieved using the service.
If you're looking to share code between the client and server I'd reccomend looking into something like RIA Services. If this isn't for you then I'd look at a few articles around about sharing code between the server and client (via Add as Link).
Hope this helps