I've a web site developed using MVC 4 ASP.net application. I'm new to .net platform & I want to add web service which would return me operating system name of users device based on certain input.
Assuming I've logic to capture OS information using inputted data, how do I go forward in building this web service?
Do I need to have a complete separate solution file which will have a web service or in existing MVC 4 asp.net application itself, should I create a new project which would be of type "WCF Service Application"? Again I don't know much about WCF service either, if I use it, how would the URL be accessible, etc?
Can anyone give me some insights?
Note: I've also a separate REST web service which is a completely separate solution with separate projects but deployed on same IIS.
Thanks in Advance!
You don't need to create a WebAPI project just for what you described (i'm assuming one or a few end points).
Simply use MVC controllers that return JSON for example, this way you deal with a single framework.
Reasons to move to Web API is if you need support for CORS, need content negotiation for results etc. From what you are describing it's completely fine to stay with MVC.
Related
I have an MVC application that uses MVC Controllers to return views. Now I want to expose an API to other applications to consume, as well as returning JSON data types for some SPA features in the same MVC. What are the differences between adding Web API Controllers to my MVC Project vs adding a whole new Web API Project?
returning JSON data types for some SPA features in the same MVC
For that case, I'll place Web API inside existing MVC. By doing so, you can share business logic, services and even models.
In my case, I have SPA silos using AngularJS, and both MVC and Web API live happily in the same web application, and share business logic and data access layers.
It is worth noting that you can share Authentication cookie if you keep MVC and Web API together. Otherwise, it is pain in the neck to authenticate in both places at the same time, because Web API is token based and MVC is cookie based by default.
FYI: In new ASP.Net MVC 5, there won't be separate MVC and Web API anymore.
The only difference between the two is reusability and good design practice. I highly recommend to use it in a separate project. Then, later on, you will be able to reuse it without much or any effort.
Another advantage to segregate is the impact on testing required for any changes made. If you keep the projects different then if later on you change anything, the domain for the re-testing efforts would also be just the second project.
I am developing an MVC5 application and use Entity Framewerok 6 code first on this. Now we we will also develop an android application that will interact with the MVC application (CRUD operations) by using the web services. At this stage I want to be clarified about the issues below:
1) I think WebAPI is better option for us as we use the services on android apps. What do you suggest?
2) In order to integrate WebAPI to an MVC project, which changes should be made? On the other hand, can we use the same controller and data layer methods (i.e. SaveChanges, etc.) by making some modifications i.e. inheritance? Or do we have to create a seperate methods for web services? Could you give an example by code?
3) Does integrating WebAPI to the MVC project affect the MVC project's abilities or methods? I mean that is there any disadvantage integrating WebAPI to an MVC project?
Any help would be appreciated.
1) That's a good idea. Web API is easy to implement and consume
2) You don't need to make changes to intergate Web API in your application: just start using it. As you want to expose CRUD operations from EF a good idea would be to implement ODATA services. Or use something like Breeze (depending on how you want to consume the services). See "MVC and Web API" bwelow
3) Web API doesn't affect at all the MVC part, unless you make a mistake setting the routes. Although they run in the same host, they work completely independent of each other.
MVC and Web API
Unless you need to do something special, like exposing Web API in a different URL or "domain name", MVC and Web API are implemented in the same web application project. To start using Web API in your MVC project simply add a new controller. Perhaps you'll have to include also the WEB API route configuration, and some other Web API configuration.
If you want to expose the EF model throug Web API you simply have to follow the instructions in the link to create an ODATA controller, which will expose the EF model as a RESTful service, allowing you to execute the CRUD operations to the EF model through URLs.
NOTE: What you want to do is a very frequesnt pattern in MVC applications: MVC is used for generating the views, and Web API fos exposing functionalities that can be easily consumed from the views usin Javascript + AJAX. Don't be afraid to use it. You'll find no problems at all
I've desgined my ASP.NET MVC application using the Domain Driven Design, and I got the following projects:
MyApp.Core - the app core, contains the domain models etc.
MyApp.Infrastructure - the app main infrastrucutre, contains implementation for the domain model storing (repos etc.) using EF.
MyApp.Web.Core - domain models, services declaration (interfaces) and such only for web (e.g. IFormAuthenticationTicketSupplier, IOAuthAuthenticationProvider etc.)
MyApp.Web.Infrastructure - web implementation
MyApp.Web.UI - ASP.NET MVC standard application.
This application should be used by enterprise with multiple servers, etc. Currently, the application calls a service in the infrastructure layer at the controllers, which uses Repositories and EF. I can connect to the DB server using the connection string.
When digging about this topic at Google, I've read that some approches taken when creating an enterprise application are create an Application server and Web server. In the application server - storing a WCF service, and in the web server just calling it.
I'd like to know if I should do so (if creating a WCF service is the right and required approch when dealing with enterprises):
- Why should someone not just use the Services in the controllers and instead use an API?
- In case I'm using an API, it won't slow down the response? since even if the computers are on the same network, I still open an HTTP request.
- If I should use WCF, or ASP.NET WebAPI?
Thanks for any feedback and help!
First, regarding your projects, is there a need to split up MyApp.Web.Core, MyApp.Web.Infrastructure and MyApp.Web.UI? Sure they may be separate responsibilities, but sometimes dependency hygiene trumps encapsulation. You can always leave them in separate folders and namespaces. I wouldn't extract something into a separate project unless I needed to reference that as a library from elsewhere.
As far as the application service, that also depends on your needs. If the only place that would call that application service is the ASP.NET MVC app, then there isn't much of a need to extract an application service. There are some benefits however. One is that you don't have to worry about all of the dependencies required for a service - you just references it via Url. And of course you have the ability to call the service from places other than the controller, although the MVC controller can act as a pure HTTP service as well. You also have the ability to deploy updates to a specific service without releasing the MVC app. But you do have the burden of maintaining a separate service. If you do go that route, go with the WebAPI, WCF is just too much abstraction.
I have an asp.net mvc3 application built with RavenDB and I want to be able to access the data via an external HTML5 mobile app. I'm thinking of exposing methods via WCF or via MVC controller action methods? Which option is best?
Ok, I have faced similar situation a while ago. This the way I have handled it, I have directly exposed Controller urls to the mobile application clients. Bascially it will help you in reducing the burden of maintaining two code bases and helps you to reuse existing functionality. Even if you go with WCF you need to expose with REST to make HTML5 client developer life easy.
This is the why microsoft released ASP.NET MVC 4 Web Apis to avoid confusion among developers which way to go in these scenarios. So that your services are device agnostic and easily testable.
Since you've already built the app in MVC3, I'd recommend a JsonResult action on an MVC Controller: http://www.asp.net/ajaxlibrary/jquery_json_data_from_controller.ashx
I'm looking at putting together a REST based system which still has a standard browser style access. My desire is to have both of these on the same machine, but what are my options?
Use IIS to host both the web-site and the REST service (different URIs, e.g. http://mysite.com/ and http://mysite.com/api
Use IIS and some magic I don't yet know to have two domains mapped to the same machine but different services (e.g. http://www.mysite.com and http://api.mysite.com
Combine the two technologies into a single service (that perhaps uses routing tables to direct the requests to MVC or WCF where appropriate).
My preference would be the third option, this would allow me to have a single code-base and single repository accessing. The WCF page on codeplex mentions in its release notes, "not tested with MVC3" - is this suggesting that this is a possible approach?
I'm not keen on using MVC for the REST implementation as it is intended that the majority of interaction with my site goes via API, so I want that as the focus.
I've ported the contact manager to use MVC 3. It definiately works though we've not done exhaustive testing. The one thing in general to cognizant of with regards to web api is that both MVC Routes and Service Route are greedy. If your default route is first then MVC will try to grab your HTTP Service requests. One thing you will want to do is put your Service Route first before your MVC routes. If you run into additional issues, you may need to use custom routing constraints.
In http://webapicontrib.codeplex.com there is a sample that works with MVC 3. It is in the Samples/experimental folder. However, it was built with a custom version of WCF Web API. I don't believe it needs to be though. I've been meaning to get the author of the sample to switch it over.