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.
Related
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've been checking quite a few examples related to Web Api, and they all create the model in the Models folder contained with the Web Api project but I'm curious as to how this should be handled if you want to use/re-use these models with various projects.
In the past, when using WCF REST, I would have created the following:
Business Model Project (PCL)
Business Layer Project
Data Layer Project
SQL Data Layer Project
WCF REST Project
Web App
Windows App
Third-Party Web app (javascript)
Mobile App (Xamarin)
Projects 2 to 9 would have all been referenced to Project 1 or objects would be created dynamically when using JavaScript. The business object project only contained POCO objects, most decorated with DataContract/DataMember attributes.
Can the same logic/Project breakdown be applied when using Web Api? Is it recommended or will I face problem at a later stage?
If it's not recommended, am I suppose to duplicate all my models? Doesn't seem to make sense so I thought I'd ask.
Thanks.
Short answer, YES. The same logic/Project breakdown can be applied when using Web Api. This is also how I implement my architecture. Your Web Api would just be another layer in your architecture. By doing it that way you will allow for greater re-usability of the models (DRY) and maintainability.
I am new to the world of WCF and MVC. Currently I have a MVC3 ASP application and a WCF service app exposing some services. I want access this service from MVC3 ASP app. As I know either this can be done by adding the Service Reference to ASP project or by generating proxy class from WCF service and add proxy class to ASP app.
My question: Is it the right way I am going (as said above). If so which method is better (adding service reference or generating proxy class and adding it manually)?
It is a lot easier to use add service reference. Add service reference basically means that you are asking visual studio to do the job that you would have done if you were generating it manually with default settings.
If you don't have any reason not to go the easier way, then my advice is to use add service reference.
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
I have an ASP.NET Web Forms application in one project. Under the same solution I have two different projects: one Repository layer and one Service layer.
Eventually I will rewrite my ASP.NET Web Forms application in MVC, therefore I want to implement all the new functionality by using MVC.
I have to create a registration form for customers and at one point if a condition verifies, I have to bring the customer to another form and then back to the registration form.
Will it work if I create an MVC application project within the same solution? The application will also use the Service and Repository layers. What about the Session object?
Just add the MVC controllers/views to your Web Forms application. They can run side-by-side just fine. This will allow you to upgrade parts of the site to MVC while keeping your existing Web Forms pages running.
The web layer (which has both MVC and Web Forms) can still access all of your application framework logic (repository, service, session, etc...)
Scott Hanselman created a Nuget Package for easily upgrading your web forms app to Mvc 3:
http://nuget.org/packages/AddMvc3ToWebForms