|
Well did you know you can make the viewstate the server's problem
Yes some pages kicks out an insane amount of viewstate , but with simple code you can hide your viewstate in a session , never to be seen by the page again.
Chona1171
Web Developer (C#), Silverlight
|
|
|
|
|
My general impression is that in order to really gain the performance benefits of mvc, I'll need to shift a lot of my logic from a server side / postback paradigm to lots of javascript handling it in the client. While that would eliminate a lot of round trip hits, not wild about javascript coding.
|
|
|
|
|
that also makes the advantage of unit testing a bit more clunky , javascript is a pain to debug . and still the bottom line is that you can achieve the exact same results in asp.net using javascript
Chona1171
Web Developer (C#), Silverlight
|
|
|
|
|
Yeah. Thus far I'm not terribly excited about moving to mvc, but I'm trying to keep an open mind so as not to miss out on any benefits just because it's not what I'm accustomed to.
|
|
|
|
|
For now my opinion is "its not there just yet"
give it a few releases, my scenario is "leaving a treasure chest of Gold"(Asp.net), for a "few ounces of platinum"(MVC)
Chona1171
Web Developer (C#), Silverlight
|
|
|
|
|
Christopher Duncan wrote: not wild about javascript coding
F***ing understatement - in 4 years of silvelight LOB apps I have not touched the horrible stuff, now I have to start relearning it all over again because the javascript I use in the 90s has morphed into something else.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Yeah, dig it. I still don't know why, twenty years on, someone hasn't written a cross platform runtime application that would allow us to write client applications via that framework. After all, a browser is nothing but a cross platform app with a crappy development infrastructure. Why couldn't we do something real, that would allow us to return to the power of client side computing?
|
|
|
|
|
Heres some code you can use in your asp.net page
protected override object LoadPageStateFromPersistenceMedium()
{
object viewStateBag;
string m_viewState = (string)Session["ViewState"];
LosFormatter m_formatter = new LosFormatter();
try
{
viewStateBag = m_formatter.Deserialize(m_viewState);
}
catch
{
return null;
}
return viewStateBag;
}
protected override void SavePageStateToPersistenceMedium(object viewState)
{
MemoryStream ms = new MemoryStream();
LosFormatter m_formatter = new LosFormatter();
m_formatter.Serialize(ms, viewState);
ms.Position = 0;
StreamReader sr = new StreamReader(ms);
string viewStateString = sr.ReadToEnd();
Session["ViewState"] = viewStateString;
ms.Close();
return;
}
however it just need some minor adaptations to account for when a user opens more than one page at the same time (you may run into corrupted state problems)
What I do is I cancatenate a string to the veiwstate id Session["ViewState"+hashkey]
and i generate the hashkey by using a SHA hash alogoritm with the current url as input , and a whipe the session on page not IsPostback
Chona1171
Web Developer (C#), Silverlight
|
|
|
|
|
|
thank you for the share, I will definitely look into this , it looks interesting
Chona1171
Web Developer (C#), Silverlight
|
|
|
|
|
Christopher Duncan wrote: However, our company has one heavily database oriented app that suffers
significant performance problems, enough to disrupt operations. I want to get it
done quickly, but it also needs to hold up under a heavy load.
Technology isn't going to solve that problem nor provide a solution.
|
|
|
|
|
I would say if you are using any kind of visual designer to build web pages, you are doin' it wrong.
Even the best tools suck at it, and it would never be scalable to different sizes.
|
|
|
|
|
It would be foolish to depend solely on a visual designer, when coding a website , and if you come from the good old dreamweaver days (remember how that used to make tables look like (yikes!!!), but consider this scenario you have never seen a project's interface before the frist time you get in touch with it is when your boss phone and say , interface broken when you click submit, so you fire up Visual studio, open the page in question using the designer click on the "submit" button and then view source. or go back to the designer and double click there you go you have the server method, all this while the MVC guy is busy typing in "submit" in search , and trying to figure out where the submit function in server side is placed because a sloppy coder decided its good to put all server logic in a single controller file
Chona1171
Web Developer (C#), Silverlight
|
|
|
|
|
And that is good?
In mvc, a submit button will create a HTTP Post, with the same name as the view you are currently in.
Imagine it breaks in the Entities page. That submit button will always (there may exceptions) launch the entities function that is marked with HTTP Post. So i can go directly there because I know that there is where the problem lies.
Instead I have to go to a visual designer that depending on the complexity of the page can take a while, and go through a bunch of hidden div's for messages and other controls just to find a button to double click it because you don't know where the damn function is?
I'de rather know where stuff is instead of going "fishing".
|
|
|
|
|
True , but no one said that the source view is not available in asp.net
I say pick the right tool for the job at hand.
Chona1171
Web Developer (C#), Silverlight
|
|
|
|
|
I am in the same boat as you (very new to MVC development). I have developed one application using ASP.NET web forms and now I am trying to convert it to MVC.
First issue you will face is to get your head around how all things glue together in MVC ( Not that hard ).
Issue 1 : If you have update panels in your existing app there is no such control in MVC so you have to rely on JQuery AJAX calls and handle data success and error on the view. So much for separation of concern!!
Issue 2 : If you are targeting multiple platforms like app need to run on computer as well as tablet you are in trouble as now you have to think about how JQuery and JQuery Mobile will spoil the fun for you. e.q. document.ready() won't work in mobile.
Making some cool looking website that does some basic stuff is good in MVC but it takes a lot of learning to produce something decent in MVC that can be called corporate application and be ready to pay for some third party controls like KendoUI to ease the pain of developing in MVC..
Zen and the art of software maintenance : rm -rf *
Math is like love : a simple idea but it can get complicated.
|
|
|
|
|
run to mvc - don't walk.
say goodbye to gargantuan viewstates
in a few months you'll wonder why you wondered
|
|
|
|
|
as someone experienced in both I say proceed with caution
if you are on a tight deadline do not even consider.
Viewstate ?
just hide your viewstate in a session and you are set
Chona1171
Web Developer (C#), Silverlight
|
|
|
|
|
I'm going to disagree .... do the job right the first time imo.
hiding the viewstate in a session is another way of putting lipstick on a pig - it's still a pig at the end of the day.
|
|
|
|
|
Now that being true still , for any server language including MVC, don't you think the preserved values for a we form is put somewhere regardless of language. I mean the page will still have it after a post-back. The sloppy thing about asp.net is that they put it smack on the web page itself
just some food for thought
Chona1171
Web Developer (C#), Silverlight
|
|
|
|
|
no - form values are sent to the controller via ajax. of course the model will need to be freshed to reflect the change and all - but there was no complete page refresh.
Kendo has a really great implementation of this.
|
|
|
|
|
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!
|
|
|
|
|
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.
|
|
|
|