I'm learning AngularJS and playing with mixing it with ASP.Net MVC. I'm wondering, should I still pass model from MVC controller to the View and then load it to Angular model? Or should I just open View without model and request data needed by $http by AngularJS? What is the preferable approach?
You should request data from AngularJS to your own controller or api, its not good practice to load all data at once with model, but part by part that is needed.
For example if you have a 1000 pages, and user comes to your website it's not good to load data for all 1000 pages. Its much better to load data for pages that user wants to see.
Related
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.
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.
I wanted to ask if anyone has tried using combination of Sencha's ExtJS 4 (using MVC approach) with ASP.NET MVC (using view models)?
I have existing ASP.NET MVC 3 app that uses view models and my question is how would this "fit" into Sencha's MVC approach...Would ASP.NET MVC "view model" become ExtJS "model" and then I would define yet another "view model" for ExtJS....Seems a lot of "translating"...
What would be the best approach?
And yes, I am aware of projects that integrate ASP.NET MVC with ExtJS using Ext.Direct, but my question is strictly relating to MVC paradigm on "both" sides (ASP.NET and Sencha ExtJS)
Thanks
Z...
Our approach currently is a what could be described as MVCCM or MVC-CM.
In ExtJs you have the view as panels and boxes etc, a store with a model makes a model and you need some logic to make these components work together which would be the controller.
This ExtJs frontend is situated in a MVC3 project and exposes controller methods that typically returns Json data which it gets from the model back end which is typically made up of entities.
There is no programmatic link between the entities on the server side and the models defined in the stores client side. One could generated the stores from entities, but we have not looked into this yet.
The view in the Microsoft MVC3 framework is just a page that returns some div tags which ExtJS can render stuff into.
While I've not done this with ExtJS, I really don't think there's any conflict. I'm assuming a lot here, I know, but if ExtJS works with JSON and you've got ASP.NET MVC actions that emit JSON, it's really more of a philosophic difference than a technical one.
One difference from a normal MVC app would be that your ASP.NET MVC app might not have any views, since the views would be handled entirely by ExtJS.
From the server side, ASP.NET MVC really doesn't care - it's getting a request that gets mapped to a controller and action, processing the request and returning some result. Whether that result is HTML, JSON, XML or whatever, ASP.NET doesn't care at all.
I am learning ASP.NET MVC, and ran across a video on the asp.net/mvc website that showed how to retrieve a value from a textbox after a postback. In the video the author simply grabs the value from the Request object in the controller.
It seems like this breaks the separation of concerns concept? By doing this the controller is now dependent upon the presence of a Request object which won't exist if one runs unit tests against the controller.
So I assume this is an incorrect way of retrieving form data on a postback. What is the correct way? Once I am in my controller, how do I get access to the postback data?
It seems there should be some intermediate step that essentially pulls the data from the postback and packages it into a nice object or some other format that the controller would then used?
The data should be posted back to your Model or ViewModel. Your controller method that handles the POST will expect the model to be provided as a parameter.
Here is a blog entry that gives an example
Using model binding, MVC can populate data coming from the form data, the query sting, cookies, and a number of other sources directly into your object model or other paramters defined as parameters to your action methods in the controller.
There's too many details of how this works to summarize here, but it is the cornerstone of the power of ASP.NET MVC.
Check out Models and Validation in ASP.NET MVC as a good starting point. You'll find tons of other resources around MVC model binding out there.
I've really liked Steven Sanderson's Pro ASP.NET MVC 2 Framework if you prefer physical books.
I've recently decided to try out MVC 2 and coming from a webforms background, I'm having a little trouble trying to figure out the best practice solution to caching data provided to a partial view (user control).
In my webforms application, I have an AccountSummary.aspx page, which has a Booking.ascx control. Booking.ascx had output caching of 300 seconds and in the Page_Load of AccountSummary.aspx, I used to check if the control was null, and if not, pass it a UserId. Then in the code-behind of the Booking.ascx, I used to make a data access call to fetch all the bookings, thus a call to fetch the bookings was made at most once every 300 seconds.
I would like to achieve the same in MVC2, but I can't seem to find the best way of achieving this because all the examples on the web seem to pass the data to the user control in the RenderPartial HTML helper method (which I don't want because on every page load I would have to pass the booking info which is going to kill my database!)
Please advise :-)
Cheers, A.
There is no simple mechanism for view-level caching in ASP.NET MVC 2.
There are some clever tricks to exploit the output caching in ASP.NET, like Donut Caching and Donut Hole Caching, but they both violate the MVC pattern (by making the DAL spill over into the views, for example), are very tricky to get right, and exhibit virtually undocumented behavior. (See the comments in the blog posts and other posts here on SO for more information.)
The short answer is that view-level caching (i.e. caching a partial view or a view, as opposed to an action method) is a trip you do not want to embark on if you are new to ASP.NET MVC. Hence, you should cache in your DAL instead, or on your action methods.
In your example, you could have a OutputCacheAttribute on an action method that returns a partial view with the booking list, or you could use the System.Web.Cache to cache the booking list when retrieving it in your DAL.