Religious question - MVC benefits vs ASP.NET?
-
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?
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
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.
-
Does that mean that you stored the state (of the answered sections) in a database instead of the ViewState?
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.
-
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.
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
-
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?
-
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.
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
-
Hopefully this doesn't count as a coding question. My boss pinged me today about considering the move from asp.net to mvc because it's supposed to be better for n-tier database and performs better then asp.net web forms. I have absolutely no experience with or knowledge of mvc, so I thought I'd see if there was a general consensus in terms of whether or not it's a better architecture to do database intense web development with. What are your thoughts?
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
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.
-
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?
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.
-
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.
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
-
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.
-
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.
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?
-
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
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.
-
Those are actually some very good points... However, I will say unit testing is not 100% of the code base out of the box, you can't really unit test the DB without affecting its state. You can't test the views without some form of automation.
Pualee wrote:
However, I will say unit testing is not 100% of the code base out of the box, you can't really unit test the DB without affecting its state
So don't try to avoid it - just do it. Presumably the comment is based on an idealistic view of what "unit" testing means? Myself I want my code to work so I make compromises to make sure I can test all of it in a repeatable way.
-
Like you, I'm optimized for development speed. 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. I'm not sure if MVC is the silver bullet many think it is or not, but I'm open to considering it.
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
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 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.
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:(
-
Hopefully this doesn't count as a coding question. My boss pinged me today about considering the move from asp.net to mvc because it's supposed to be better for n-tier database and performs better then asp.net web forms. I have absolutely no experience with or knowledge of mvc, so I thought I'd see if there was a general consensus in terms of whether or not it's a better architecture to do database intense web development with. What are your thoughts?
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
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.
-
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.
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
-
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; // throw new HttpException("The View State is invalid.");
}
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
-
learn mvc and don't worry about knockout or bootstrap for now. json is just a way of formatting payloads on the wire - don't sweat it - it's lean and mean as opposed to xml - that's all. css is what it is ... you want to use it in your presentation layer if you plan on using html ;-) in other words - learn to walk before you run. there are plenty of free online tutorials (MS has one, Pluralsight, etc...). I guarantee you - once the lightbulb goes off you'll be asking yourself "it can't be this easy..."
Rene Pilon wrote:
once the lightbulb goes off you'll be asking yourself "it can't be this easy..."
To be honest I felt the same way about xaml binding and MVVM, what a struggle that was coming from a winforms environment. Now we have a "framework" with all the bits required to pull together a LOB app very quickly and we have to go back to square one again with MVC :sigh:
Never underestimate the power of human stupidity RAH
-
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.
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
Christopher Duncan wrote:
not wild about javascript coding
Fucking 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