12

To many of you this will sound like a ridiculous question, but I am asking because I have little to no experience with ASP.Net Webforms - I went straight to ASP.Net MVC.

I am now working on a project where we are limited to .Net 2.0 and Visual Studio 2005.

I liked the clean separation of concerns when working with ASP.Net MVC, and am looking for something to make webforms less unbearable. Are there any recommended patterns or practices for people who prefer asp.net MVC, but are stuck on .net 2.0 and visual studio 2005?

Improve this question
2
  • Thanks for all the suggestions guys - wish I could pick more than one answer.
    – jlnorsworthy
    Mar 12, 2011 at 2:25
  • 1
    I do hope that your new assignment is only for an existing project rather than something starting from scratch. There are many basic things on which you will have become dependent upon that will be missing such as using Linq for simple queries on collections. A major frustration will come from looking at the generated HTML and seeing that it's nothing like what you expected. Good luck, and I hope that you are successful.
    – Chris
    Apr 11, 2011 at 2:39

5 Answers 5

Reset to default
7

I would recommend Model View Presenter ( MVP ). We used this on a recent WebForms app and it increased our testability and allowed us to enforce separation of concerns.

http://msdn.microsoft.com/en-us/magazine/cc188690.aspx is a great article by Jean Paul Boodhoo on this pattern; the code download is good also. You may find you don't need DTOs and interfaces for DTOs though.

Another good article is this one on codeproject.com: http://www.codeproject.com/KB/architecture/ModelViewPresenter.aspx

Edit: there is also a framework called WebForms MVP but I don't know much about it.

Improve this answer
3
  • Webvorms MVP looks really cool, but the project seems to have stalled (last release in 07/10). There isn't a lot of documentation or tutorials available
    – jlnorsworthy
    Mar 10, 2011 at 6:06
  • It also seems to require .NET 3.5 SP1 so might not be too useful for you. However, samples and source may help you evaluate the MVP pattern.
    – Ciaran
    Mar 10, 2011 at 13:52
  • Good point, I didn't even notice that. I'll keep my eye on that project in the event that I have to do webforms with a company that has current technology :)
    – jlnorsworthy
    Mar 12, 2011 at 2:26
4

I would recommend for you to understand the page life cycle of .net 2.0

These videos might be worth watching although not all are free but at least this will be a good start for you.... The thing is this will give you idea on what to further research later on.

Improve this answer
3

As you might have discovered by now that you would need to unlearn couple of things that you did learn with ASP.NET MVC (btw - the same happens when an ASP.NET person jums on to learn ASP.NET MVC). You can still implement MVC pattern in ASP.NET but the seperation of View and Model is very blurred in ASP.NET due to the eventing/page post back architecture.

In my opinion, Most of your new learning will be related to Page Life Cycle and Eventing & Controls. The usual stuff Session, Cache, ViewState and DB interactions remain the same.

HTH...

Improve this answer
2

Checkout Front Controller pattern and Implementing Front Controller in Asp.Net. Do these things only if your project is going to be of good size. Doing this for a small project will not justify ROI.

In a small project you can try to set some guidelines. For example - No business logic, no session use etc. in code behind.

See what fits best in your case. In any case hold the temptation to do over engineering.

Improve this answer
0

Back in the dark days of .NET 1.1 I created (I guess like everyone) a sort of MVC system for an application that went like this.

A page was made to be a sort of 'fake' master. This had some plumbing to show menus, scripts, styles, etc.

The 'views' were individual user controls.

There was a table with information about each view. For example, 'Product' would load ~/Controls/Product.ascx into a placeholder. The table also had a field that contained the type name of the model class (as if). Each model implemented a well-known interface. This class was instantiated using Activator.CreateInstance() and called to initialize, and was then passed to the control itself (inversion of control?). The control then called various methods to get datasets or whatnot. The interface itself was normalized to have the usual CRUD methods (Read/Write/List/Delete). There was also DAL/ORM layer below this.

It wasn't pretty, but it worked well. It was easy to test and develop against, and most developers that came on board would catch on fairly quickly. Most of all, it was relatively simple to create.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.