Religious question - MVC benefits vs ASP.NET?
-
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
-
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
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?
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
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.
-
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
-
Just use Flesk.NET ViewState optimizer http://flesk.net/components/vsoptimizer.aspx[^] It can store Viewstate either in Session State or on disk server side (compression optional).
-
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
-
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.
I know that I personally embraced web development only after asp.net and web forms arrived on the scene, for the exact same reason that you mentioned. It abstracted html / http development (which was an incredibly bad thing to have turn into the de facto development platform) and made it feel like normal application programming. Some of the things that were used to accomlpish this sleight of hand (view state appears to be the front runner) also contribute to poor performance, hence mvc. Or at least so I've surmised thus far. I still think writing a serious application in a browser is patently bad idea, but like you, I get paid to give the people what they want. So, most of my work is web develoopment. Like you, I also care about the future, so your point about Mvc is also relevant. Of course, honor requires that I first serve the needs of the people who pay me, but if I can do that and serve myself at the same time, everybody wins. Nonetheless, there's a reason web forms provided an abstraction layer on top of html. Not at all enthusiastic about entering the wild, wild west of native html / javascript and the wonderful world of browser incompatibilities. Write once, debug everywhere.
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