|
A couple of gigs ago, we replaced an admittedly bad ASP.Net site with an MVC4/Razor site. It was a handful of SPAs using partial views and Ajax post-backs. Blindingly fast and a much better user experience - go for it!
|
|
|
|
|
First of all, ASP.Net MVC is "NOT" better than ASP.Net Webforms. Both are different frameworks for different use. Both have Advantages and Disadvantages over each other. Many people have wrong idea that 'MVC' is the new version of 'Webforms' and they should move to MVC just because it's so much better than Webforms (If you believe this, you lack information about both the framework). Microsoft is going to develop both the frameworks in parallel (Webforms is not going away).
I have been using ASP.Net Webforms since last 6 Years, and ASP.Net MVC since last 2 Years. Here are my thoughts...
Webforms Pros: Your team already knows this, Richer controls, Years old methodology, Much higher talent available in the market, Easier to switch (PHP or Java developers have to learn only new syntax and not new concept)
Cons: Unit Testing is not as seamless as MVC, Viewstates are making it little bit heavy compared to MVC, Lesser separation of logic compared to MVC (this is debatable)
MVC Pros: Seamless Unit Testing, Clear Separation of Logic (this is debatable), More control over UI, Lot more code will be generated automatically for CRUD, Cleaner HTML Pages
Cons: Completely new concept, No Design View, No more awesome controls, Big learning curve for your team. Less mature compared to Webforms
Before you consider switching to MVC, you need to address two main questions.
1) How many developers are going to transitioned to MVC?
If lot of people from your team has to learn MVC, then this is unnecessary exercise. Because the gain could be balanced by purchasing more computing power (this is cheap nowadays), and spending little bit more time on Unit Testing. compared to having every one to learn new methodology.
2) Are you going to rewrite existing application to MVC, or going to start a new application.
If you are going to write a brand new application with the MVC, then it's OK. But if you are going to rewrite existing application, then you are looking for trouble. The rewrite will cause new bugs, your team who just learned the new concept, will face new challenges. and you could have added lot more new features to you Webforms application in the same efforts, instead now you have added new bugs and the new features are now in a pending state.
So is it worth the time and money?
When I switch to MVC, I remember struggling for a month changing my mindset to a new concept. And now I know MVC and we have launched our awesome product, it's cool and I like it. But I still haven't found a single deal-breaking advantage of it over Webforms.
Because at the end of the day, it's all about profits and making your clients/users happy. and how technically awesome it is, doesn't really matter. 
|
|
|
|
|
Thanks, man. That's exactly the sort of balanced, pragmatic comparison I was hoping for. There's a huge amount of religion involved in any tech conversation and I'm less interested in pursuing the One True Path than I am getting it done in the real world, where they pay me to produce results in a timely fashion.
Like many of us, I came to web dev via native Windows C / C++. Webforms provides a nice crutch to hide the stateless nature of http so that application developers can focus on the application. From the little I've read thus far, it seems that the weight of the viewstate used to accomplish this is among the biggest criticisms of webforms.
MVC is promoted as having better performance because of the lack of viewstate and a focus on client side technologies. That said, it's been my experience that the closer you get to raw html and jscript, the more time you spend screwing around with browser dependendant nuances (aka bugs and deficiencies).
All of this has led me to embrace the server side, application perspective of webforms over the years. As a corporate developer, I'm optimized for development speed. You're never given a reasonable amount of time to get it done, so I like tools that let me get it done fast. Abstraction from stateless protocols, browser versions, etc. lets me focus on functionality.
With all that said, the db app I'm working on is coming up next to another webforms app that has long standing performance issues. There's attention to making sure mine doesn't suffer the same. I'm not opposed to moving to MVC if it'll build a better performing app, but I don't want to find myself mired in endless html / browser specific debugging or other things that would slow me down. Would value your thoughts.
|
|
|
|
|
Good insight,
You know what irritated me during tech ed was that no one was using webforms , it kind of creates the perception with managers and technical architects that MVC is the new ASP.net granted it has some cool stuff but with MVC at its current state I cannot within any reason believe that a MVC developer can outcode and release faster than a asp.net developer of equal measure. unless its a "hello world" app.
MVC is slightly faster I will admit , but with bandwidth increasing and our mobile phones being able to outrun what we considered fast pc's 10 years ago , I really think coding for the sake of faster code kind of like paying double for a package to arrive 5 minutes earlier.
Chona1171
Web Developer (C#), Silverlight
|
|
|
|
|
You do know that the most used web frameworks are MVC based, don't you?
Spring, Zend, Symphony, Cake, Ruby on Rails, Django, CodeIgniter just to name a few.
More details here
I work in a PHP (using Zend Framework) and .Net shop and those PHP devs who tried ASP.MVC found it easy to learn as it's similar to ZF.
|
|
|
|
|
There are so many benefits to MVC:
- Due to a brittle and convoluted way of doing things they will have to hire ten more programmers and you will become their manager, which is kinda of a promotion.
- Because there are no more controls, you will have to hand code every single piece of crap, which will make your system truly unique.
- Because Microsoft kinda bundles their implementation with their wonderful almost divine version of an ORM you will get to experience the wonders of flexibility (and performance) that an Entity framework enables.
etc etc
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Brittle and convoluted I can learn. The lack of controls I've read about is indeed one of my concerns.
|
|
|
|
|
Sure, controls are gone, but now there are HtmlHelpers. There are some good ones built in, you can write your own, and there are some good libraries out there, like HtmlTags
|
|
|
|
|
What I'm really curious about is whether the performance gains are worth the reinventing of the wheel. Any perspective on that for a global database app (one Sql Server db, located in Atlanta) that lives at the mercy of the Internet bandwidth / speed of various countries?
|
|
|
|
|
The performance gains I saw weren't from the database perspective. Web forms has a lot of overhead in maintaining the view state. I had pages where the view state caused total page size to go into the Megabytes range. MVC doesn't track any kind of view state so that overhead doesn't exist. That doesn't mean MVC can't track form state or page state, it's just done differently.
|
|
|
|
|
Yeah, it's the view state that seems to come up most often. For database considerations, the data that needs to come across the wire has to come across the wire so there's not much you can do about that.
Heavy view state coupled with a lot of postbacks, however, could be a significant hit. We've had demos where it worked fine in most countries but the users in Hong Kong experienced poor performance because there were Internet speed / bandwidth issues. While there's nothing I can do about their local connectivity issues, the more stuff I have to drag across the wire, the more pronounced the issue will be. This is one of the areas where people are advocating mvc.
|
|
|
|
|
I made the push for my team to switch from web forms to MVC earlier this year. None of us had any experience with MVC, and had been using web forms for years. The entire team now hopes they never have to work on another web forms application again! Our development time is much shorter with MVC, and the apps are unbelievably faster.
Aaron Throckmorton
|
|
|
|
|
I don't have much love for javascript / client side code, which is one of the things I've enjoyed about the c# / code behind world (virtual though the states may be). My perception is that mvc is a largely client side, raw html / javascript / jquery world - is that accurate?
|
|
|
|
|
It can be largely client side, if you want it to be. But really it's mostly server side, IMHO. You manipulate your data and make all your decisions in the controller, then send that to the view, which renders it for the client. When the user clicks, it calls another action in your controller and you do everything there. MVC works really well even without using any javascript or jquery.
|
|
|
|
|
That's encouraging, especially if there's a reasonable way of doing server side stuff and still being able to interpret the state of controls. I truly detest the stateless nature of html / http.
|
|
|
|
|
You can read pro's and con's all over the place until you are blue in the face, so let me just be a witness to what happened in my company:
We where starting a new project, the first lead used ASP.Net, which is where I learned it. We had 6 months to deliver, and we delivered it right on time! In the second, I asked for 2 weeks to do a ASP.Net MVC proof of concept for the next phase. The idea was to have the whole app use both.
The reason I wanted to use ASP.Net MVC was because we had to render some dynamic forms. With things I had learned in the MVVM world, I had a feeling that ASP.Net MVC would do some binding between the model type and the view to simplify things exponentially.
The second phase was more complex: the dynamic forms, integrating with the old code, and other new features. We had another 6 months, we got it done in 4!
The speed and easy of doing it in ASP.Net MVC was simply amazing, I knew it would be faster, but I didn't even begin to imagine it would be as fast and easy as it was.
Disclaimer: MVC programming IS a different way of thinking. I, personally, have been thinking in the MVC way for a while because of the MVVM programming I have done, I am positive that foundation helped greatly in speed things up. My point: If you are not use to thinking in the MVC fashion, it might take a bit more time to come up to speed then it did for me.
P.S. If you do go the MVC route, make sure you learn and use a Direct Inject (DI) library of some sort. SpringFramework.Net is a good option.
|
|
|
|
|
Thanks, man.
My perception is that you end up doing a lot of client side coding in this model as opposed to the server side / postback / viewstate paradigm of webforms. Would that be correct?
|
|
|
|
|
No, not dynamic via the user, but dynamic via the database. It was a government form that has up to 25 sections for one 'assessment' and can have up to 16 different configurations of those 25 sections. Rather than having 16 different views, the questions and response types came from the database. Strongly typed partial views where used to render the correct html for the question/response type.
|
|
|
|
|
Sounds like a good use for it.
|
|
|
|
|
Does that mean that you stored the state (of the answered sections) in a database instead of the ViewState?
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Forgive me, but I am a bit rusty in ASP.Net, the day this project was suppose to go out for beta, it was announced that the company had been purchased by a Java shop, so I have been doing Java for the last year.
To the best of me knowledge, ViewState is a ASP.Net thing, not a ASP.Net MVC thing. Correct?
The basic layout was the use of two models: The lower model, I called simply the model. This model's job was to get the data from the database to the controller. Then I created a view model that had extra view related info that never went to the database.
|
|
|
|
|
I was just curious. The state of the answered sections must reside somewhere. In WebForms you could use the ViewState to retrieve and store such info without hitting the database every time (if you don't want to explicitly persist it beyond an user session).
In MVC you either have to store it in a database with all the overhead associated with it, or manually hand code hidden fields of some sorts without any encryption.
Correct?
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Actually in the MVC world, similar to the WebForms world, you have the session variable. I simply stored the metadata that was used to generate the HTML in the session variable. Personally I am not a big fan of the ViewState because that means a huge amount of network traffic to your client that simply does not need to happen. I prefer to rely on skilled developers and network admin's to optimize the system to hand session info correctly than simply send it all to the browser when I don't know the type of connection the browser has access to.
|
|
|
|
|
Unfortunately I was afraid that the answer would be exactly something like this: Sessions!
http://stackoverflow.com/questions/10181629/why-session-is-a-disaster-in-asp-net-mvc-application
Storing state in a session vs. a client side persistence. If you are looking for some scalability you cannot really rely on sessions for big chinks of data.
Anyway, lack of tools for persistance is one of the many fundamental flaws of MVC.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
I agree, persistence is a fundamental flaw of... I have many years of experience in desktop development, only a few years in web development... it is my impression that persistence is the Achilles' heel of web development in general: Either you store lots of stuff on the server or send a lot of stuff across the wire to and from the client all the time. There are lots of different ways to skin the cat, all have pluses and all have minus, there is no one perfect solution. Am I missing the silver bullet?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
