Religious question - MVC benefits vs ASP.NET?
-
Brittle and convoluted I can learn. The lack of controls I've read about is indeed one of my concerns.
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
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
-
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.
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 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".
-
We are in the process in making the change from Silverlight to MVC and the differences are huge, mainly because I don't have any real depth in aspx/javascript. If you already have these skills I imagine the transition should be reasonably simple. I am continually astonished at the number of different tools needed to achieve a high level of interaction that is automatic with xaml binding.
Never underestimate the power of human stupidity RAH
Mycroft Holmes wrote:
I am continually astonished at the number of different tools needed to achieve a high level of interaction that is automatic with xaml binding.
I couldn't agree more; my company is in the same boat as yours. I'd kill for a simple {Binding Model.Property}.
-
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
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.
-
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 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 v
-
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".
-
That's what my senior dev keeps reiterating, and then starts talking about knockout, json, boostrap, css and other (to me) esoteric stuff.
Never underestimate the power of human stupidity RAH
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..."
-
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
-
Mycroft Holmes wrote:
I am continually astonished at the number of different tools needed to achieve a high level of interaction that is automatic with xaml binding.
I couldn't agree more; my company is in the same boat as yours. I'd kill for a simple {Binding Model.Property}.
-
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 v
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.
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
-
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?
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 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?
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
-
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?
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
-
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?
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
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.
-
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.
-
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?
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 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.
-
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.
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
-
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.