I want to build an ASP.NET MVC3 application but instead of a model I would like to use a web-service. (WVC -Web-service - Views - Controller instead of the traditional MVC3, Model - View - Controller).
The reason behind this selection is the need to use the same database for a Windows Phone Application and a Website.
Which is the most "proper", "correct" way to use webservices in my application? Is it better to call them from the Controller? Or use them from the Model?
I am new in Asp.Net MVC3 and I would appreciate any help/suggestions.
Thanks
I'm not entirely sure of what you mean, however my take on your question would be as follows:
If your web service is serving up xml or JSON you would consume the service & deserialize related data at the controller level. In the event you need to present information to a user you would populate a model / view model from the previously deserialized data and render a view.
In the event data needs to be passed back to the service the data would flow from the view into the controller to be serialized and sent back to your webservice.
Related
I would like to save data from MVC view to the database without navigating to the controller? Is this possible? If so how can I achieve it?
Thanks in Advance
While technically possible, all backend access should happen in the controller, if you want to stay true to the MVC design pattern.
Note that you can submit data to a controller action using AJAX, so the page from which you send the data will not be reloaded. For example, use jQuery.post.
I have finished a few MVC partial views which load their data using calls to a webapi Get method, to preload the data used by the angular controller.
This method works but it feels more logical to do this via the initial asp.net-MVC Partial view load via #Model for example. Rather than waiting for the page to load and angular to call the get method of my webservice i could have prepopulated the Model, but im not sure how this would pass the data to Angular using this method.
I have had the same issue (if one call this an issue) and ended up doing binding the model to the partial view at the server side. The main rational for the decision was that the model was already available at the time at the server side and I was not building a Single Page Application.
Had I been developing a SPA, I would store the partials as templates at the client side, then grab the model via WebAPI and do the binding
If you use AngularJS,then it's not need ASP.NET MVC. Just use web api for get data.I written a demo site for AngularJS+ASP.NET WEB API,hope to help you,this is the source code.
Does your web page have a lot of heavy client-side interaction or are you simply using Angular to initialize the data for your page on load?
If there's a lot of client-side interaction, you will probably want to keep using Angular. If not, you might want to go back to using MVC since your use case doesn't really require Angular.
Right now I have a few layers to my project: Core <> Repository <> API... and I'll be building a "client" MVC web project layer. My question is - where do viewModels belong in this architecture?
Should the controller methods of the Web Project call the API (multiple times - getTheseObjects, getThoseObjects) to get data, and then build the viewModel? Or should the API support calls to construct the viewModel so that only one API call (getAllObjectsForThisPage) needs to be made per page for the application?
Your view models will belong in your client MVC app. They will be specific to the views in that individual client application, and usually will get populated by domain objects.
This is how it can work: the controller mediates the https requests thus calls a API endpoint and receives some data or domain objects, which in turn you use to populate your view models.
Take a look at automapper if you are returning domain objects from your api, it really helps with mapping domain object to view models.
You can place ViewModels into your MVC application, but you could create something that is called DTO (Data Transformation Object) and return that from Web API to your client. In essence it will be a class with only the necessary information that you pass to the client. If you want to call that ViewModel you might as well go ahead and call it like that. My suggestion would be to issue one call and to return all the necessary information. One call one trip.
My practice usually is to separate ViewModel from MVC and store it in some other project. The service layer would prepare a ViewModel and return it to MVC. The reason for this is that once I had a requirement to build WPF application after MVC was completed. It was quite a pain moving things around and retesting everything to make sure that it still works fine.
I am trying to grasp many concepts that are new to me and I need some clarifications on the best way to create and pass my strongly typed model from my MVC Controller to its Razor view using a Web API.
As seen in many examples, you usually create your model from some repository and then pass it to the view (strongly typed or not) and then use the Razor syntax which gives you access to your model to build the html not necessarily having to use JavaScript.
Where things get complicated for me is when I want to make use of the Web API to create the model I want to use just like I would use it as I describe in the previous paragraph.
Should I call the new HTTPClient to call the Web API service from within my controller?
Will I need to deserialize and format the response? etc...
I always see calls and manipulations from scripts within the view...
Could someone point me to the right direction?
Thanks.
If your WebAPI is a separate endpoint i.e. not part of your existing site, then yes you will have to send a HttpWebRequest from inside your controller and then serialize the data from the response and pass that into your view.
Alternatively you could call the API directly from inside your view via AJAX, however, I am not sure if you need your controller to do something with the data before it comes down to the view.
The project I'm currently working on has a Core API which is used by everything: services, web, ...
This API has following layers:
Core
Core.Models
Core.DataProviders
Core.DataProviders.LinqToSql
Core.Utils
On top of this API is my ASP.NET MVC application. This looks like this:
Web
Web.Models (Some Web specific objects and logic. For example a class which builds a list of quarters to help me render a day in a scheduling table.)
Web.Extensions (Html Helpers, Controller base..)
Web.ViewModels (Composite objects to pass to the View.)
Web.Services (Layer which communicates with the Core and Web.Models. This layer builds ViewModels for my Controllers. Helps keeping my Controllers clean.)
Any serious flaws in this setup?
A more specific question: I need to parse some things coming from my View before I can pass them to the Core. Should I handle this in the Controller or in the Service layer?
Generally speaking data submitted from the view should be parsed by a ModelBinder, falling back to the Controller if using a ModelBinder doesn't seem to make sense.
Parsing in an application service makes sense if multiple sources can submit the data in the same format (like web service or file system persistance).