I am trying to get a hold on WebAPI so please excuse if the question is too naive to ask.
Been hearing that WebAPI is using MVC and is integrated in to it.
Just created a sample WebAPI project but under References I find not System.Web.Mvc dll.
Why? Or am I missing anything important?
EDIT:
About System.Web.Mvc, the MSDN says the following paragraph:
The System.Web.Mvc namespace contains classes and interfaces that support the ASP.NET Model View Controller (MVC) framework for creating Web applications. This namespace includes classes that represent controllers, controller factories, action results, views, partial view, model binders, and much more.
And it should not be there. ASP.NET Web API is very similar to MVC, buit is not integrated with it or whatever. Web API can live completely outside of MVC framework perfectly fine. Which is good - while building HTTP service you wouldn't want to include any HTML rendering features whatsoever into your project.
Think of it that way - System.Web.Mvc contains end-user-facing features that MVC uses, like views, view results. WebAPI is not a end-user-facing thing, it does not generate HTML or run javascript. Purpose of Web API is to provide means for creation of HTTP services - very different from MVC framework.
MVC and Web API share several similar approaches. Take controllers for example. Looks like they behave similar in both frameworks. However you may discover that implementations are different. MVC uses System.Web.Mvc.Controller, while Web API uses System.Web.Http.ApiController. More detailed explanation on the reason why is here. On the other hand - routing. Both frameworks use the same implementation of routing which resides in System.Web.Routing.
Frameworks are similar, but can exist completely separately. That is why there is no reference between them.
For Visual Studio Express 2013 for Web do the following:
New Project > Web > ASP.NET Web Application > Web API > OK
This should work, the Add folders and core references for: MVC and Web API should be automatically ticked by VS.
100% working - I've just created a project and all the references are there.
Related
I am trying to figure out how to possibly configure the use of different Service Containers for different routes/endpoints in a ASP.NET Core (.NET 5) application.
The background is that we have an application on ASP.NET 4.x that allows for plugins to register their own routes/endpoints (under configurable prefixes - that is also something I need to figure out in ASP.NET Core) - each such plugin gets its own Castle Windsor container where it can register services and other things with services we pre-register in that container. This container is also used to activate any ASP.NET WebApi controllers for that particular plugin.
We have done this by building some custom routing on top of ASP.NET 4 WebAPI/MVC where the route has information about which context it originates from (The core Application or a Plugin) as well as automatically prepending the prefix.
However, ASP.NET Core WebAPI/MVC has changed allot of things and I can't quite figure out how to get to the same result.
Because this is driven by plugins, it doesn't have to be done on a PER route basis obviously, instead PER plugin is good enough (Which would be a group of routes under the same prefix), so I have been trying to figure out of any of these provided a viable path for me:
Application Parts
Feature Providers (that container application parts)
Controller activators
I did try out a combination of all the above where a ApplicationPart would return custom implementation of types, there by letting us carry extra info about the controller to the IControllerActivator. However ASP.NET Core requires RuntimeType's rather than just any "TypeInfo" implementation.
I had a similar question and ran across this blog post which provides an example of using different IServiceCollections for different route prefixes. I think you can adapt it to get what you want.
Apparently the author also published the code in the WebAPIContrib.Core library (nuget package here).
The question is very simple,
I am using Clean Architecture for a project(web site) by using ASP.NET MVC. I download the Clean Architecture template sample code written by Ardalis from GitHub.
In that specific template, the writer didn't use the viewmodel.
Does anybody have any reference for a template using Clean Architecture and viewmodel for ASP.NET MVC etc or know where to put(layer) the view model.
I'm the author of the CleanArchitecture template in question
The latest version uses ViewModel classes with Views as one of several options (the others being Razor Pages, APIs with Controllers, and APIs with API Endpoints). Typically when using ViewModel classes the usual convention is to put them into a ViewModels folder in the root of the Web project.
This puts them near the Views folder so they are fairly easy to find (and for API Models used with API Controllers, frequently these are placed into an ApiModels folder that sorts near the API and/or Controllers folders typically used in these cases).
It's worth mentioning that this problem goes away if you use Razor Pages, because the model is linked to the "view" (the Page) in the approach.
Likewise for APIs, if you adopt the API Endpoints approach (another open-source package of which I am also the author), the Request and Response models used for each endpoint are typically linked to the Endpoint class there as well.
Right now the API and MVC controllers are in same project and that is fine. Later I will add a Angular frontend. But since the angular front end is a separate project wouldn't it make sense for the ASP.NET core MVC views to be a separate project? Any links anywhere how to do this ? I imagine this way the 2 view (Angular and ASP.NET core MVC) would both call the WEB API layer and that seems more logical. ..
Or if they stayed in the same project I should atleast have the MVC controller call the WEB API controller? Or no ?
If I understand correctly...
You have a MVC application which also has some API controllers in it. You are adding an angular project which needs to call the API controllers and you are wondering if you should move the API controllers into a separate project?
If so then.... probably.
In doing so the API would become your central source of business logic and the MVC app and Angular app two different presentations of that central logic.
But ultimately it's an architectural decision which you need to make based on how you see the solution moving forward.
So if it helps:
Reduce complexity
Helps the code follow the SOLID principles
Stops you from breaking the DRY principle
Allows for better separation of concerns
The time and cost to do so is acceptable
Then go for it.
You may find that the MVC project and API project have shared dependencies. So you may end up having to move things like Models or Entities into their own projects too so both can reference them. You may also need to think about authentication and how that will work and consider something like identity server.
Hope that helps.
I`ve already asked for something here Update view in response to web service requests AND I got the answer for most important question however I have another one related to this.
I have 2 projects in my solution (actually more but others are irrelevant in this case) - ServiceStack web services which is library type of project and MVC application. I would like to use mvc app's functions or variables (so share MVC project's memory with web service). I can do this if I move web services classes into the main project but I would like to keep it separated. I, of course, already added web service's project reference into main project (MVC) but I can't add main project references info web services project because it says that it cannot be done because it would result in circular dependencies, which isn't anything strange.
What's the best solution to either share memory between these projects or provide a communication channel between them. I don't want to, for example, make requests to my controller's public methods. I know that when you face circular dependencies it means you did something wrong while designing a solution but in this case these 2 projects are separated only to separate web services classes from the main project.
You should add a third project that includes all the common classes you need to use from both your projects.
Look at the MVC Integration and ServiceStack Integration wiki pages for docs on integrating between ServiceStack and MVC. e.g. if your MVC Controller inherits ServiceStackController you'll have access to ServiceStack dependencies and IOC to resolve any registered dependencies. You'll also be able to call ServiceStack Services directly.
We've got a solution with multiple MVC web projects and now adding a client-facing WebApi project.
The API will be a much more scaled-down version of what is available through any of the web projects (though it will likely expand much more over time), so we've come to a decision-making point for how to handle the Models.
What are the best practices for handling Models across different projects?
It's my understanding that a Model in a WebApi project will, for example, use certain property attributes which are meaningless to an MVC web application. And also as an example, the Display attribute is meaningless to the WebApi, but very useful in a View.
This leads me to believe I should be creating a separate set of Models for the WebApi, but also wondering if I'm missing something.
I understand that this could be a question that may lead to a range of opinions, so I'm mostly looking for what are considered industry best practices.
In my solution where i have Web API and MVC web app, I have the below structure
Models : My Entity/Business objects. These are created by Entity framework from my database. These are almost same as my db structure. My Repositary methods (for data access) returns either a single instance /collection of instances of this classes. My data access project is a separate class library which has been referred in other places like my web api project etc..
Web API ViewModels : The Viewmodels (POCO class) specific to the Web API interfaces/action methods.
MVC Web app ViewModels : The Viewmodels (POCO class) specific to my razor views. I had even inherited few of these from the Web API Viewmodels and added additional properties as needed.
I use a separate project for the DTOs, so that the projects that need to consume them do not get into issues with circular references.
I would have the WebApi project map your models into the DTOs. If your MVC project is consuming the WebAPI output, it just needs a reference to the DTO project. This keeps you from having to refer to the WebAPI project directly.