views:

356

answers:

6

MVC + classic webforms in the same website

Now I am wondering if it was possible to mix MVC and classic webforms (I don't want to reimplement what I've already done even if this makes the code non-homogeneous...)

Original question

The more I improve my understanding of ASP.NET (and web programming in general) the more I dislike ASP.NET page-lifecycle and its winforms-like paradigm. I'm more and more convinced that I'd get better results in less time by writing by own handlers or, at most, using plain .aspx templating without any databound control.
Every time I learn the ASP.NET-way of doing something I'm left with the feeling that I have wasted my time and I end up re-inventing the wheel.

Do you proficently use System.Web.UI.* controls?
Don't you get confused by the page lifecycle?
Don't you feel like that putting a SQLDataSource on each page produces unmaintainable code?

Update

I couldn't belive I was the only one who felt like that and now I know I was right. I'm watching some videos about MVC and it looks exactly like what I was looking for. Tomorrow I will install and try it out.

+4  A: 

ASP.NET MVC was created exactly for people who feel the way you do :)

Yes, it's perfectly possible to mix WebForms and ASP.NET MVC

Praveen Angyan
Whoa, I just discovered that SO does use MVC. I was wondering how those pretty urls were possible in ASP.NET without hacking the ASP.NET request pipeline
Utaal
@Utaal They will be possible in next ASP.NET for web forms too.
Arnis L.
@Arnis - yes, I just read something about it, thank you@Praveen - thanks for the link about mixing the classical and MVC approach, this answered my questions completely
Utaal
+1  A: 

Yes, some people dislike the often called "leaky" abstraction that is WebForms. It attempts to turn stateless browser requests into a beast resembling a stateful form application, not always successful and usually not gracefully (large viewstate hidden fields, broken back button functionality, reliance on javascript for simple navigation).

That's a big reason why Microsoft developed its MVC implimentation. It gives you a "native" web interface, without the abstraction, while maintaining some helpers (which it actually calls helpers). Prior to MVC it was also possible to write your own non-webforms application on ASP.NET, it just meant more work (I personally was using my own home-brewed system built on HTTPHandler to provide RESTful urls and non-webform interaction for about a year before MVC provided an official alternative)

David
"Native" web interface is just what I have been looking for...Yes, "It attempts to turn stateless browser requests into a beast resembling a stateful form application", that's exactly what I hated most
Utaal
In which cases is the back button "broken"? Never experienced such an issue with ASP. sites...
Genady Sergeev
A: 

That's kinda winforms thing, tho ... to provide some higher level abstractions to try and make it seem less like you're developing for the web. The more you learn about web development, the more you will want those abstractions stripped away. If webforms is an automatic transmission, then ASP.NET MVC is a stick shift. It strips away a lot of the abstractions and gives you gun metal access to what's going on.

JP Alioto
+1  A: 

I went from classic asp and php to .net. At first it was difficult. I kept thinking that I could do things much faster in classic asp/php and that my results would be much cleaner and lightweight.

To answer your questions:

Yes (it took a while)

No (Not sure why I was never confused by it since a lot of people are)

Yes (but you don't need to use them)

Now going "back" to asp.net MVC I feel I can do things much easier in webforms. I'm starting to get the hang of it though. It's all come full circle but better.

As many pointed out, you might like asp.net MVC better if you haven't tried it already.

metanaito
A: 

Don't you feel like that putting a SQLDataSource on each page produces unmaintainable code?

What? Why aren't you using SqlConnection?

Spencer Ruport
Of course, but I still had to write SQL inside the pages (what an horror to me, where is logic and interface separation?) to make the VisualStudio databinding + GridView + DetailsView magic happen... or do everything my way and feel like there's something wrong somewhere...
Utaal
Hmmm I always used SqlConnection -> Data Access Later -> Repeaters
Spencer Ruport
+1  A: 

Do you proficently use System.Web.UI.* controls?

Not anymore.

Don't you get confused by the page lifecycle?

Used to. Particularly when custom/user controls were mixed in.

Don't you feel like that putting a SQLDataSource on each page produces unmaintainable code?

Sure it does, but no one forces you to use SqlDataSource. I prefer ObjectDataSource with 3tier architecture.

Going MVC way is dissapointing sometimes. The obvious stuff like paging and sorting needs to get reinvented (open source stuff usually doesn't fits all your needs). Even more important - MVC project can easily become a real mess if you don't know what you are doing and not keeping it well organized. But in hands of professional - MVC is a nuclear weapon.

Be careful. :)

Arnis L.
"I prefer ObjectDataSource with 3tier architecture.", so do I, but I have to manage a database with more then 50 entities/tables and the model would get overwhelmingly complex.I've tried Pylons (an MVC oriented web framework for python) and I really liked it so I think I'll appreciate ASP.NET MVC too, but thanks for the advice.
Utaal
We had more than 200 foxpro tables. Somehow it worked (3tier architecture). Now i'm trying to figure out Domain Driven Design. Anyway - good luck! :)
Arnis L.