There is a similar question already asked by someone BUT it was related to ASP.NET MVC and not Web API. I have some common code which I want to execute in every action in Web API certain controllers. What is a good way for such situation?
ASP.Net Web API and ASP.Net Wep MVC has the same core. Also you can use the same answer describe in your link :
creating a BaseController and inherit all your controllers
creating an ActionFilter like here
Related
I am starting to work on a new project so working on laying on the architechture at this moment.
So basically we want to keep a service oriented architecture using MVC web api.
So I had the following structure in mind:
Project.Core (All Poco classes)
Proect.Data (All entity framerwork)
Project.Service (All Web API ??)
Project.Web
We would be working for the first time on webapi here. So wanted to know how do we intergrate webapi here.
Most of the articles we saw read had created a mvc web application and had selected webapi in that. But we
were looking to create separate service layer just for webapi. Is this the correct practice to do that or
I am missing something here.
We basically wanted not to have a tight coupling b.w MVC web and web api here. If we create web api as part
of mvc then how can we separately access our web api.
WOuld appreciate inputs.
I normally use the project template provided by Visual Studio. Choose Empty ASP.NET project template and then select Add folders and references for Web API. It will create the folder structure needed/recommended purely for a Web API project without any MVC reference. I generally create a separate project for Data Access and use that from the Web API project.
I have a theoretical (and probably foolish) question about web api and an mvc webapp in .Net Core.Seeing as they overlap in Core, it's even easier to have an api and visual app in the same project, responding to different routes - great!
But, there's something architecturally fundamental which I always struggle with : Let's say I had a web api, which other services use to do some data things and some custom actions etc. Then, I also have a big mvc app, this is the central app (let's say for argument).. Here's the question.
1) Should the mvc app be making webapi calls over http(even though they will likely run on the same box - they dont have to of course), 2) Should the mvc app be sharing the service and repository classes with the webapi?3) Should the mvc app be programatically calling webapi from mvc?(i.e. injecting the webapi classes into mvc controllers - therefore having a dependency on deployment, but abstracting the api logic and avoiding http)
Please don't let me know if this is stupid question...
I wanted to get some thoughts about API access either through WCF or MVC. Either works, but I like the idea of using MVC to build custom routes. I know this is possible with WCF (maintaining the request routes), but aside form the security disadvantages of not using WCF (which are not deal breakers) what other thoughts does the community have regarding this.
I have a project where we have been discussion using MVC or WCF and we are comfortable with both, but we are swaying towards MVC.
You should use the new ASP.Net MVC Web API framework, new to MVC 4.0.
I think MVC makes a great web API. I did this not too long ago for an android app that uses a RESTful web API using MVC 3. Here's a good tutorial:
http://msdn.microsoft.com/en-us/magazine/dd943053.aspx
If you're feeling adventurous check out the Web API framework included in MVC 4. NOTE: I have not experimented with this yet but plan to in the near future. See here: http://www.asp.net/web-api
If I need to build a web application that implement functionalities related to managing an Medical hospital institution. That application include functionalities to add, update, delete, search and retrieve patients, medical visits, etc.
So I am confused on which approach to follow inside my ASP.NET MVC web application, either to have my controller classes inside my asp.net MVC.
Derived from IController to perform the CRUD operation
OR
Derived from ApiController to perform the CRUD operations
SECOND question is there an approach that is taking over the other, and what are the advantages/disadvantages of each approach over the other?
You can absolutely use both. Nothing stops you to use good old Controller to do CRUD in JSON and MVC is capable of doing it. However, you do not get all the nice features of Web API such as content negotiation, message handlers, media type formatters, etc.
If you do not need any of Web API specific features, then use MVC. But on the long run, Web API will be a better investment as I believe adoption will rocket soon.
If you are going to generate classical HTML pages from your controllers, use the MVC ones. If what you want to return to a client is some kind of serialized data (XML, JSON, ...), use Web API controllers since these make it easier, regarding e.g. content negotiation.
See also Getting started with Web API
What's the best way to structure the base functionality of an ASP.NET MVC 3 solution so it can be reused in subsequent solutions? For example, I'm going to develop a basic skeleton MVC app with user registration using email verification, enhanced users/right/roles, blogging with comments, and a forum. I understand maintaining the business logic in class libraries but how about the controllers and views? Do I basically have to just copy and paste my base solution to create each of my new solutions?
Creating a Custom ASP.NET MVC Project Template
templify