Abstract: Should I choose ASP.Net MVC over Web Forms or [closed]

坚强是说给别人听的谎言 提交于 2019-11-29 01:19:46

问题


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)

Some 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 -

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 :-)


回答1:


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.




回答2:


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.




回答3:


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.



来源:https://stackoverflow.com/questions/3778455/abstract-should-i-choose-asp-net-mvc-over-web-forms-or

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!