I see lot and lot of advantage in using Knockout.js in my MVC project but before going for it I want to make sure if there are any implications of using the same, or precautions to be taken while using Knockout.js
KnockoutJS is included by default starting with ASP.NET MVC4, so it's safe to say that you're going to see it a lot in ASP.NET MVC going forward.
Ultimately there aren't any conflicts of any sort that you have to worry about with Knockout with ASP.NET MVC. It doesn't conflict with any of the DataAnnotations or other auto-scaffolded JavaScript.
You don't get any knockout scaffolding for free (not like DataAnnotations and jQuery validation) so you only use it in instances where you explicitly code it into a view or partial yourself.
I use Knockout heavily in MVC4 and in Node.JS applications and it works great in tandem with jQuery - never ran into any issues with it on either platform.
Related
I am new to net5 framework and have some questions regarding the structure of the project.
When we create a new project it will only create the razor pages. I am learning that we can achieve things with these razor pages.
Meanwhile, I have looked into some open source net5 projects on GitHub and see that they are also using MVC.
So, my question is why do we need MVC then? If everything is achieved using razor pages then what is the need for MVC?
If we need MVC then should we use razor pages with them too?
I have done the identity work with razor pages using scaffolding. What would happen now if I add MVC to my project. How will I manage the routes and page redirection from razor pages to MVC and vice versa?
Please help me with this so I can clear my concepts on this.
I will be really thankful to those who explain the scenario to me.
Thanks
First, .NET 5 is out of support. You should target .NET 6 instead.
Razor Pages represents a simpler way to generate HTML on the server compared to MVC. It is recommended for all new web applications that rely on server-side HTML generation going forward. MVC is still available for existing apps. It is also probably easier to migrate older MVC 5 (.NET Framework) apps to ASP.NET Core MVC when porting to .NET Core.
Razor Pages is built on top of the MVC framework and depends on a lot of the features of MVC such as model binding, action results and so on.
If you are using Razor Pages, there is no compelling reason to also use MVC in the same project, although you can. If you do, then you need to register controller endpoints:
app.MapControllers();
You might need to add controllers to your project if you want to create HTTP service APIs, although you can use the minimal API feature that was added to .NET 6 instead:
https://www.mikesdotnetting.com/article/358/using-minimal-apis-in-asp-net-core-razor-pages
Razor Pages can make coding page-focused scenarios easier and more
productive than using controllers and views.
https://learn.microsoft.com/en-us/aspnet/core/razor-pages/?view=aspnetcore-6.0&tabs=visual-studio
As another difference, in MVC, you usually create separate class for ViewModel. As I understand, in Razor Page, you don't need a separate class and you just add more properties in the same page and those properties will be part of your model which make things easier.
I am going to start work on a SaaS based application. I need to decide whether to go with ASP.Net MVC or web forms application. Through various posts I came to know that both are good, they are not replacement of each other and so on.
Also, I know traditional web forms method, I am not aware of MVC, I need to learn it first.
Please guide me which approach is better.
Thanks,
Vijay
i can just share some of my experience as i have worked on both
i preffer asp.net MVC over Asp.net because of the futile layer of abstraction that Asp.Net has over basic HTTP architecture
the user controls in asp.Net induce unnecessary markup
ease of using ajax in asp.net mvc compared to updatepanel(in advanced senarious)
support of razor type syntax increases productivity
no overloading by things like viewstate
because everything is managed by the programmer soem of the typical issues that arise in asp.net like the problems in dynamic controls are no longer present
so if you ask me go for asp.net MVC
There is no right answer here. I prefer MVC but if you already know ASP.Net WebForms it probably is easier to stick with that.
I'm wondering about one thing - as we know, the MVC pattern is stateless (it doesn't use the ViewState, so we use only HTML controls), but if we use them in WebForms as well, it'll become stateless too ? so, by doing this, we are getting closer to the MVC pattern ?
You get closer to one aspect of MVC i suppose but its still a night and day difference.
MVC is fundamentally about the model view controller pattern, not what kind of controls your using to write your code. Unless you implement an MVC pattern within webforms (which people did a lot before ASP.NET MVC was released) and migrate away from the postback model in webforms then your platform is still considerably different.
If you want to do that then just use ASP.NET MVC.
ASP.NET WebForms is stateless too. All HTTP communications are. ViewState is just a way of preserving some state by hidden form fields which' values are encoded.
There is nothing stopping you creating your own hidden fields in MVC to make it 'kinda stateful'.
No we don't use HTML controls in ASP.NET MVC. We use HTML helpers. There's a big difference.
I think you're confused about what stateless means. All web development is stateless, in so far as the server sends down a page to the client and then forgets about it.
.NET tries to make it "easier" by using ViewState and Session, but MVC and Web Forms are stateless.
MVC is an architectual pattern. It can be implemented in any language/framework/environment (although some make it easier than others.)
I don't know why you would attempt to apply MVC to webforms when all the work has been done for you by Microsoft to implement MVC in ASP.NET with ASP.NET MVC...
As with any software models, there isn't necessarily a hard-defined line between fundamental principles. I've been developing applications with loose implementations of MVC in WebForms for years.
The lack of pseudo-state (I won't give WebForms the credit for actual state, the web is stateless) in MVC is one of a number of aspects of the ASP.NET implementation of it, it is not part of the actual MVC pattern.
On top of all this, I can see why people miss Web Controls and want to use them in MVC. But why would you want to use HTML helpers in WebForms? If you're willing to do this type of groundwork then you probably should be using MVC.
Is there any ajax toolkit for asp.net MVC
As MVC does not have ViewState or the Web Forms postback model the AjaxControlToolkit will not work with it.
There is a project to do this (http://mvccontroltoolkit.codeplex.com/) but it's not yet released.
There are numerous blogs where have got different controls working but to be honest I'd suggest looking at jQuery and its plugins (http://www.jqueryui.com/). MVC lends itself far more naturally to these, it is not control-based.
Here's another resource talking about this: http://www.hanselman.com/blog/ASPNETMVCPreview4UsingAjaxAndAjaxForm.aspx
In addition, ASP.NET MVC lends itself quite easily to making your own amazing ajax controls, especially when combined with jQuery.
The emphasis in ASP.NET MVC is more on HTML and client-side code when talking about user-control similar to those in the AJAX Toolkit - you may like to check out the excellent http://www.jqueryui.com/ for some good client-side controls.
I've been tasked with making a prototype web application, and i'm debating between using ASP.NET WebForms or the new ASP.NET MVC.
There is a commerical ASP.NET UserControl that i would like to use that gives me 95% of the functionality i need (and it does it in an AJAX-y fashion). But i've heard that since ASP.NET MVC doesn't use ViewState, it can't run these WebForms-based controls.
So, is that true or false?
I'd really like to use this commerical UserControl, but i want to use ASP.NET MVC if i can, and only if ASP.NET MVC is not going to give me much trouble when trying to use the WebForms-based control.
Traditional WebForms and MVC aren't mutually exclusive; you could run both of them in the same site. For an explanation of how to make this happen, see this post by Scott Hanselman.
So you could, for example, create WebForms-based page(s) to leverage the commercial control, and use MVC for everything else. You could also set up a simple test to see if the control can operate without ViewState -- making it OK to use in MVC -- and fall back on the hybrid approach.
It probably won't work. There is no viewstate, postbacks (in the Webforms sense) or page lifecycle which most commercial controls rely on in some fashion.