|
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?
|
|
|
|
|
You are probably right, there is no silver bullet, I am just skeptical that MVC is the answer, especially not the MS version of it.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Well, I have spent a year with Spring Framework (java), ASP.Net MVC is light years ahead of Spring Framework! What I have seen of both Ruby and Django, they also have a huge leg up on Java. For me, having a tight integration between the template language and the core language is vital to get the most out of the MVC, not something you have in the Java world
|
|
|
|
|
I have done extensive research on the very question you have posed as I have faced the same problem; should I move to MVC or keep working with Web-Forms. This question took me nearly two years to resolve since I had to decide where my career skills would be most benefited. Since I have been in the field for a very long time this decision was more than just where a specific project may lead but more importantly how I wanted my skill-set to develop since you cannot really concentrate on both; you just don't have the time.
All this being said here is my answer to your question...
In a word, stay with Web-Forms. Now here is the "why"...
MVC is an excellent paradigm to work with. It is well crafted and makes a lot of sense from a technical perspective. However, that is all it does. It offers absolutely no benefit to a project's business requirements and nor to the company's IT department as a whole in general. And this is MVC's biggest drawback.
If you look at every positive reply posted here you will find that practically none will support a benefit to a project's business requirements.
True, Web-Forms can be a bear at times to work with but developing with Web-Forms is much easier with far less client-side coding involved, which is more difficult to test. And JavaScript is a horrendous language to work with; not because it is a bad language in of itself but the actual front-end support for debugging and working with it is still rather crude. jQuery makes some of it much easier but adds a truck load of raw code that has to be transferred over the wires to your front-end. And you have to learn how to use jQuery well to make it worth your while.
MVC is also very limited in what you can do with the front-end when compared to what Web-Forms offers in terms of server-controls. Yes, they can be weighty but so will your MVC when you find how much you have to code from scratch to make it worthwhile.
If you decide upon MVC you do it because you and your team will enjoy working with it and you understand its inherent limitations, especially when your project may be up against a deadline with a boat load of user requested features. Its a paradigm with a very nice framework. However, that is all it is.
You can do the same and even more with Web-Forms with less overall effort.
In terms of performance, there is absolutely no difference in terms of overall application performance as both methodologies have their own performance negatives. And you can develop a very slow MVC application with a very fast Web-Forms application running right next to it.
MVC will also not prevent you from poor coding practices, which can be found in any type of project no matter the paradigm being used. And you can develop a very nice modular-based Web-Forms application with nearly the same style as that used with MVC. I do it all the time.
MVC has been popularized by the younger and newer technicians to the IT field. And its "cool" to use new technology. However, most new technologies these days are highly redundant and really offer very little in terms of better development practices or performance gains because no matter what you use on the Internet you are still interfacing with 1970s technology in terms of Internet architecture.
Steve Naidamast
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
Thanks, Steve.
From what I've seen, beyond religion (the coolness factor, etc.) what I've seen thus far about performance is the complaint about the weight of webform viewstate & server side postbacks. Shifting to a client-centric paradigm with javascript & jquery might have some advantages in that regard, but for just the reasons you've mentioned I'm not at all wild about a significant chunk of my codebase being client side javascript. And yeah, browsers are a crappy, pseudo-green-screen 1970s develpment platform to begin with.
|
|
|
|
|
Ah I see you have posted it here - have another upvote.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I have been researching the same thing, and wrote a reference application in MVC and Razor for us to use. But before I actually got to recoding all of our applications, we noticed that Web API had gotten popular and was what was really needed to write for smart phones and implement all of the latest flashy glitzy stuff on the web in JavaScript. I had been thinking of using WCF and web services a few years ago, but Web API is so much easier and cleaner. So, my current track is to write an MVC Web API that matches the CRUD classes we have been using, then writing clients for our applications in JavaScript and AngularJS, using jQuery AJAX calls to get and put the data via a Web API. AngularJS data binding is similar to that in XAML for Silverlight and Windows Phone and is getting to be much more popular than Knockout. The main advantage is that, once you have a Web API, you can write clients for phones and desktops without changing the back end. The server part no longer needs MVC to present data to web pages, so all my work with Razor is being discarded. Silverlight, which I was going to use for SharePoint versions of the apps, has been deprecated, so that has also been discarded, although the XAML experience might come in handy, if I ever write a native front end client for Windows Phone. Of course, we long ago lost the ability to code visually, and lots of people are sad about that. However, there are more IDEs and tools springing up to make coding in JavaScript easier. I am still learning. Hopefully, I will actually be able to implement what I learn before it gets obsoleted yet again.
|
|
|
|
|
Bruce Patin wrote: Hopefully, I will actually be able to implement what I learn before it gets
obsoleted yet again.
That's always the challenge, isn't it? 
I'm hoping there's a decent path to mvc that doesn't require becoming a full time javascript programmer. I still find client side coding to be a primative experience from a development point of view, and it's easy to go down the rabbit hole of the various browser bugs and quirks.
Some of the replies have said you can also get good performance using a server side approach, I'm hoping that's the case.
|
|
|
|
|
It looks like the previous responders have covered this pretty well. I recently had to make this decision for a project, and I went with MVC. Based on my experience, one scenario in which I might consider Web Forms over MVC would be if I had deal with heavy use of 3rd Party controls (DevExpress, Telerik, etc). Even in that scenario, at least DevExpress provides MVC extensions that are easy to implement for the most part.
|
|
|
|
|
We're using DevExpress controls, and while I like their functionality, they're very heavy.
Also, I read that their mvc controls are actually built on top of the web controls, view state and all, so I'm not sure if I'd use them in an mvc app or not.
|
|
|
|
|
There are some benefits to MVC, but if they are worth it or not depends on you (and your team).
In general terms, WebForms has gone to great lengths to abstract away the web portion of development. Also, there is a tendency for many developers to mix the business logic and the display logic together. (And in all honesty, sometimes it is hard to not mix them from my point of view.)
As for using AJAX, WebForms makes the easiest stuff easier, and much beyond that harder. (And the hard stuff near impossible.) While MVC doesn't try to hide as much from you and thus many actually find it easier in the long run.
Now for database work, along with MVC comes the WebAPI which makes it easy to create a service that can be consumed by clients not coming from the .NET sphere. (This is only good if you actually have others trying to consume your data.)
From my perspective, there is also more demand for developers who know MVC. It is the latest shiny thing that gets jobs. And being employable by the next company is always a concern for me. So if I have a chance to progress my resume while working for my employer, I take that opportunity. One could argue that in enough years, it will be easier to find someone to maintain MVC than WebForms.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
