views:

175

answers:

4

I've been working with web for over 7 yrs and I've upgraded from html->ASP->ASP.Net and now the new flavors of ASP.Net itself. I was to begin with MVC last year but due to deadline and the complexity involved in MVC I couldn't. Now, once again there's a new upgrade - I've begun with the ASP.Net DD (Dynamic Data) Templates (the latest one which scaffolds the DB tables and gives a list, details, edit & delete wizard).

As I dig in I get to know that its based on MVC and so I'm going to be using MVC (via DD) to built my web-apps. I've reviewed many articles and comparison videos between MVC & Web-Forms. There're a lot of topics even on SO, my abstract links are in the below reference section. Indeed MVC proves to be a more 'controlled' and 'extensible' web-development pattern however, as some say Web Forms still resides beside it (like for building a heavy data-driven apps, etc.. i.e. Sharepoint)

My web solutions are for supply-chain (user has to login to proced) and so I don't need the features of SEO or other things useful for a typical web. To simplify, I do some inventory maintenance (view, add/edit, delete & link) screens and a few complex screens like parent-child Grids & some tabular layouts. The goal remains to keep things simple yet appealing and @ the core we've performance & usability (most work with least clicks)

So, here're few of my doubts as a newbie MVCian:

  • Web forms is event driven where as MVC will do this via Actions defined in Controllers
  • It doesn't matter whether I use L2S or EF, my business logic goes in model (also extended by partial classes)
  • URL-Routing will extend my power beyond the traditional Querystring approach
  • I'll be able to render my cascaded complex tabular layouts & Grids by using multiple views (i.e. partial views & user-controls)
  • Things like sub-total, Grand-total, etc.. kind of calculations will be possible in views (hope views can share / pass data mutually)
  • Some funky GUI features like Frozen Grid-header/footer, scrolling rows, tab-view, etc.. won't lead me to a messy view (or atleast this is feasible in a clean/organized fashion)
  • I won't really have a 'Viewstate' - in that case where to store temp data? like current pageindex, sort order, etc..
  • I'm afraid MVC might lead to a complex\lenghty system where the flow is lengthy. Will I get lost? Is it scalable if I organize well?

Actually, theres more but I hope based on the above Qs you experts can figure out the kind of web-apps I work and so I just want to start investing in something better. Can't afford to change the architecture/approach every 6 months!

Does DD make MVC implicit? Then how can it use web-form controls? Sorry if I'm confusing, in that case please correct me!(most work with least clicks)

Finally, Can this be a solution: http://www.hanselman.com/blog/PlugInHybridsASPNETWebFormsAndASPMVCAndASPNETDynamicDataSideBySide.aspx


Also see the EDIT section.

Reference urls: (hope this helps others like me)

S*ome good refs about MVC over web-froms* & comparison -

http://forums.asp.net/t/1459417.aspx (benefits of MVC over a well designed web forms application) http://www.matthidinger.com/archive/2010/02/17/why-i-love-asp.net-mvc.aspx

Fire in the hole :-) http://codebetter.com/blogs/karlseguin/archive/2010/03/11/webforms-vs-mvc-again.aspx http://www.codethinked.com/post/2010/0 http://www.codethinked.com/post/2010/01/22/Controls-Do-Not-Make-You-More-Productive.aspx


Some more views on this debate:

v.good article: http://msdn.microsoft.com/en-us/magazine/dd942833.aspx

Summary of above: http://mvark.blogspot.com/2009/08/aspnet-mvc-vs-web-forms.html

http://www.asp.net/mvc/tutorials/asp-net-mvc-overview--cs http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx http://codebetter.com/blogs/karlseguin/archive/2010/03/11/webforms-vs-mvc-again.aspx

From SO:

http://stackoverflow.com/questions/30067/
http://stackoverflow.com/questions/361620/asp-net-mvc-vs-webforms-for-first-page-load-speed-for-big-projects/
http://stackoverflow.com/questions/712220/whats-your-choice-for-your-next-asp-net-project-webforms-or-mvc/
http://stackoverflow.com/questions/661181/asp-net-mvc-vs-webforms/
http://stackoverflow.com/questions/1035642/asp-net-mvc-vs-webforms-speed-and-architecture-comparison/
http://stackoverflow.com/questions/837831/mvc-versus-webforms/

EDIT #1:

Thanks for expert comments and review. I'd like to share some of my screens - if anyone is interested to let you know the kind of GUI features and Grid-cascading I've been using -

alt text alt text alt text

Plz do not confuse me witha newbie web-dvpr. I'm experienced I just need to know (like when I say "Will I be lost") whether achieving a feature rich GUI is achievable and how was your experience in doing such things .. hope that helps :-)

+2  A: 

I'm afraid MVC might lead to a complex\lengthy system where the flow is lengthy. Will I get lost? Is it scalable if I organize well?

Well, part of that depends on how quickly you pick up the technology.

Overall, ASP.NET MVC is just as scalable as any WebForms solution, and, in my limited experience, probably even more so. You have to remember that MVC is a pattern that is not new - it has been utilized by application developers for years. It is not even really ALL that new to web development, although ASP.NET MVC makes it very easy to do which is one of its appeals.

Some of the traditional advantages of ASP.NET MVC, such as testability for example, go a long way to making the overall project easier to maintain and quicker to build. I built my first ASP.NET MVC website within a week's time, hooking into libraries that had been developed years before, but providing a front-end web-interface. It really was that simple.

The question you asked of: "Will I get lost?" really depends on you and the application you are developing, but only you can answer that. You do have to be willing to put time into learning and understanding MVC...because you are coming from a WebForms background, there will be changes that won't be familiar to you.

Either way, I personally recommend the use of MVC, but, as always, it depends on your project needs.

Update: My own experience with MVC has been extremely positive. I know and understand WebForms just because of using it for the past few years, but I recently started a project at my company and, because I was given the leeway to choose the technologies that I wished to use, I decided it would be interesting to try the MVC model within a web application (the web application is a requirement). My team and I had experience with MVC in desktop applications, but we were all inexperienced with web development in general (as a whole).

The ASP.NET MVC experience was extremely smooth and it was an easy transition for my team to make. I ordered some books for the team, we spent a bit of time coming up to speed in our understanding, and we then began to develop (requirements had already been completed before this step - we were at implementation phase). Like I said previously, it took a week and we had already made great leaps forward - productivity was, and still is, very high. I am very pleased with the MVC model.

You appear to be concerned that the MVC model is going to cause your application to turn into a pile of mush, or to become unwieldy to maintain. As a whole, this is far from the truth. The entire idea of separated concerns makes MVC ideal for scalability of an application, as well as increasing its maintainability and testability. With that said, a lot of how well the application grows depends on your team's understanding of the MVC paradigm and their skills as developers. MVC is not for everybody, nor is it for every project. There are also many other factors to take into consideration with respect to scalability that has nothing to do specifically with MVC (design of the database for example has a HUGE impact - probably more than whatever development paradigm you choose). I personally like ASP.NET MVC, and have had a very good experience with it, but you have to take into consideration all the aspects of your project (team members, time allotted, budget, etc) to make a final decision.

JasCav
Guys when I say "Will I get lost?" I just want to know your experience. Remember those old VB apps which got messy when we go for a big form or some rich features. Web is no longer 'simple' now client demand even more features then windows
Hemant Tank
@Hermant - Updated the answer with the information you are asking. MVC will work for you, as long as you are taking all the factors into consideration (described above).
JasCav
@JasCav - thank you v.much for sharing your experience. That consoles me a lot and supports my decision of going with MVC .. MVC2. And one last Q did you happen to have a look at the latest 'ASP.Net Dynamic Data' (http://www.asp.net/dynamicdata) - it automates a lot and though it has server-controls still it follows MVC!
Hemant Tank
@Hermant - Glad I could help! (If you feel this helped answer your question, I would appreciate if you accept the answer.) To answer your other question, I have not yet looked at Dynamic Data (I am still fairly new to ASP.NET MVC). Good luck to you!
JasCav
A: 

asp.net mvc is more like web thing than webforms that are closer to winforms in a sense. i m also new to asp.net mvc and i would encourage u to join and feel state of the art experience. i have been developing in mvc for last six months with no prior .NET or web forms experience and i m happy i took this route. yes there are problems but they are interesting and appealing and there is whole big community to support u. yes there is no viewstate but u can still put ur temporary data in tempdata and viewdata arrays that belong to controller class and are accessible in views. more u go through article more u will find things stopping u from mvc. yes there are hurdles and difficulties but as folks say we will cross the bridge when we reach there. just give it a try and u will enjoy

Muhammad Adeel Zahid
+1  A: 

I’ve been using MVC since it was first released. My main reason for wanting to use MVC was due to the fact that SEO/page loading times is an important factor in the web applications I produce and I grew tired of other developers abusing ViewState within our applications despite my frequent explanations as to why 80k of ViewState on the homepage is unacceptable.

I wanted to make use of the Routing Engine for lovely RESTful urls as at that point in time I was using IIS7 for url rewriting on production but didn’t have it available on my dev machine. Using Routing meant I didn’t have to configure the rewrite rules again when deploying to IIS7 since the routes are in code within the application. A Routing Engine is now available in ASP.Net 4.0 Web Forms so you can easily switch from using QueryString parameters.

Note: you ask where you can store temp data such as page index, sort order etc. I commonly tag these onto the URL. This approach works with both Web Forms and MVC e.g.

http://example.com/products/1/asc

http://example.com/products/2/desc

When I first used MVC the immediate thing I noticed is that state management and validation takes more time to implement for user forms with many fields, checkboxes, drop downs etc. This WILL increase your dev time since you have to write custom code to retain state and if you want JavaScript client side validation you need to roll your own also i.e. no required field validators. ViewState is not evil and it is easy to minimise ViewState in a Web Form application. The developer who misuses ViewState is the evil one.

In summary many of the functional requirements you mention e.g. funky GUI features, url rewriting as opposed to query string parameters, calculations etc can be achieved with both MVC and Web Forms and from the end user perspective the website will look the same. The biggest thing that MVC offers is the convention of the design pattern. The reason I forced MVC within my development team is that I wanted the developers in the team to follow the same convention and thus allow us to pick up each others code more easily. What I also love about MVC is that it makes SoC (Separation of Concerns) much easier to achieve. You don't mention TDD (test driven development) in your post, but making TDD easier to achieve is something that MVC also brings to the table.

BradB
80k of viewstate? You had it good. I've seen upwards of 500 at times.
Bennor McCarthy
You shouldn't need to spend too much "..more time to implement.." state management if any - MVC is designed to make failed form posts seamless by retaining state in the form itself (as opposed to viewstate) but yes, if you need to you can revert to the `TempData` object which exists exclusively for the purpose of porting "ViewState users" over to the MVC paradigm.
cottsak
You can use the routing engine with WebForms too.
Hightechrider
More time to do validation? No way. Adding validation is absolute cake in MVC (particularly with DataAnnotations). Adding client-side validation is even easier than cake (three lines of code). Check out Scott Gu's post for more info - http://weblogs.asp.net/scottgu/archive/2010/01/15/asp-net-mvc-2-model-validation.aspx
JasCav
JasCav - that is still more work (and time) than simply dragging on a RequiredFieldValidator and setting a few properties on the control?
BradB
Cottsak - if you have your post action accept a FormCollection then you do have to write a little additional code to retain your state, for example if you want to return a form back to the user displaying validation errors while remembering their original posted values. I know it's not THAT much more, but it is still more work than with Web Forms. Especially if you have 30 input fields on a page.
BradB
How about validations like "email duplication check" - is it possible during the usual OnEmailFieldChanging event? Can I access DB and check that validation? This is simple with web-forms.
Hemant Tank
@BradB - Not really. The problem is that, in your situation, the control is what has the validation aspect. In the case of DataAnnotations, it is the property itself that has the validation associated with it. This is a very nice separation of concerns (don't mix business logic with the view) and, ultimately, increases DRY and improves the overall architecture of the application.
JasCav
@BradB: you wouldn't have the action accept all the individual fields in that case. You'd have a model object or a ViewModel object that the action accepts. That object would encapsulate all the parts of the form in a single place. MVC looks after wiring up the object to the form. Everything is typed and easier to maintain. This is a common theme in MVC.
cottsak
@JasCav: very valid point however the control that MVC offers ultimately increases dev time for the "doing" part - validation was a point I highlighted as a basic example where there are no drag and drop controls to do the work for you. In fact I too, always have my validation logic in my Business Logic classes in the same way proposed in your example. But that method regardless of the DRYness of it and the architecture going forward requires more lines of code and ultimately leads to more dev time in the scenario where one would use Required Field Validator controls.
BradB
@Hermant: There is no "OnEmailFieldChanging" event with MVC since there are no Web Controls. You would have to roll your own logic for this (or find some helper/plug-in from the community). If you rely heavily on the existing drag and drop controls such as SqlDataSource, GridView, Required Field Validations etc that are available with Web Forms then I would get your head into some example MVC projects such as NerdDinner (ask Google) before you take the plunge.
BradB
@Cottsak - that approach is not always that useful with complex forms that have various drop downs, checkboxes etc. Also, in your example how does the object/view model get created? Exactly, it has to be coded with supports my claim as an example of increased development time when moving from a Web Forms paradigm.
BradB
@BradB: When you say "how does the object/view model get created" do you mean instantiated or coded? because coding it makes no difference - you'll need to design classes to carry data at some point. As for the instantiation, the `DefaultModelBinder` creates the instance provided it has a parameterless ctor - this is pretty typical usage btw. Not only is using model objects from data layer to view useful but it's recommended. MVC encourages developers to use a lot of proven and well established design patterns whether the developers know they're using them or not - one of it's many benefits.
cottsak
@Cottsak: I mean coding the class. Coding it does make a difference, it takes thought process/key strokes. Not every developer out there creates a class for their data objects. If they don't normally work in such a manner and are WebForm drag n' drop monsters then forcing these conventions on a mixed team of developers will likely make project take longer. I've been involved in several enterprise level MVC apps during which time I've seen many a WebForm developer become unstuck by MVC, usually by the lack of ViewState, validation controls, gridview or autopostback="true".
BradB
@BradB: Fair call. No doubt it takes learning, just like anything. MVC was pretty screwy to me the first time. But i'd measure the difference after the learning - is the dev cost then still higher? I'd say no.
cottsak
@Cottask:I think yes. How much longer I guess is based on the skill of the developer(s). My response to this post was in context to the OP i.e. a seasoned WebForm practitioner taking the plunge, so I made a more direct statement about a project taking longer. I consider myself well seasoned with MVC and every once in a while I still encounter instances where I think "there is a control for that in WebForms". I think this is simply because WebForms is packed with productive user controls that are designed to save time and the law of averages suggests some of these will be missed when using MVC.
BradB
+1  A: 

I am currently working on an ASP.NET MVC web application and have looked at both Java Spring and Rails in my own time and if you are willing to work outside of the Microsoft ecosystem then I highly recommend Rails as the most productive of the three. The hype would tell you that it is 10X faster and from what I have seen that does seem to be a reality and not just hype.

Also from what I have read ASP.NET MVC takes a lot of it's design from rails but without the productivity and ease of use gains.

And yes I realize you have no experience outside the Microsoft ecosystem but rails is very easy to learn compared with ASP.NET MVC and Java Spring/JSF and well worth the effort it will take to learn.

Down vote me I dare you.

ealgestorm
Downvote? Kiddind? This is great! Rarely is there advice from users of all three popular MVC frameworks. Interesting point about the productivity optimizations of RoR vs aspnetmvc. Can you expand on those?
cottsak
@cottsak - Well, I am not the downvoter, but responses like this aren't really all THAT helpful as Rails is not really in this guy's radar. He is asking, "Is it useful to switch to ASP.NET MVC from Webforms?" Not, "Which MVC framework should I use?" It's equivalent to someone asking what car they should buy and someone telling them all the different means of travel and why the airplane is the best one. (Summary: Too much irrelevant information is just as bad as not enough.)
JasCav
Upvotes are for answers that are "helpful". This is helpful (very IMO). That's all.
cottsak
Hemant Tank
@JasCav I write answers like this because too often people seem welded to Microsoft and it's offerings for Software Development. My Goal is to get people to think outside the box that Microsoft puts developers in.
ealgestorm
@cottsak The big advantage that Rails has over ASP.NET MVC and Java Spring/JSF is that the investment of resources required to get a web application is significantly less. I like rails because like a good software engineer I'm lazy and would rather not have to reinvent the wheel every time I start a new web app which is a lot of the work involved, most it in the database/orm/business objects layer the rails abstracts away.
ealgestorm
@ealgestorm - I definitely understand. It's good for individuals to look outside what they are used to. I came from a Java world myself. (New company was all Microsoft-based, so that is when I made the switch.) Of course, one thing to remember is a lot of people are welded to a certain solution because of company decisions and decisions made that a developer has no control over (which sounds like the case for this question). So, while the information may be good, it may not always be useful for the question being asked. That's all. You still gave good information (and got upvoted for it).
JasCav