Are there any design patterns for WebForms?
As I might have mentioned previously, I really don't like WebForms. I think it's a crutch for Visual Basic form-monkeys which majorly slows you down once you actually try doing something instead of just cobbling things together.
My problem is that I mostly get WebForms applications to maintain, and it seems like every developer on the planet has a very different view on how to work around the thing. But when yesterday I spent six goddamn hours trying to implement a "make the page not refresh when the dialog shows up" feature request, I started to wonder - is there any agreed-upon way of writing those apps in a way that separates the WebForms stuff into an easily modifable view? Some analogue to MVC, with an easy way of passing data between pages while avoiding having to do postbacks every time you pop up a dialog?
For those interested: the app was in 70 percent a single-page monstrocity which had bits and pieces of various controls thrown together and serves as what should have been about nine separate pages, but instead was cobbled together into one. The dialog in question was a checklist, which was the same for two different entries - and instead of just having two controls of the same type, the original developer used one and had it data-bind to different things depending on the state of the page (which itself was a 20-entry enum). So I did the logical thing and refactored it into two controls, and then spent five and a half hours hunting down all the problems that came with having two identical fucking controls on the same page.
What's stopping you from doing MVC in WebForms?
What's stopping you from doing MVC in WebForms?
You mean the design pattern, or the framework? If the former, it's mostly that I'm looking for a way to sanely workaround the coupling between controls and code-behind (you can't really remodel your view without remodeling the whole code that deals with it). And the point of the question is pretty much "how to make it otherwise".
If the latter, I'd rather not spray odd MVC bits in an app that already consists of bits and pieces strewn together with barely any rhyme or reason. Unless, again, there's a sane way.
You mean the design pattern, or the framework?
You asked about design patterns.
If the former, it's mostly that I'm looking for a way to sanely workaround the coupling between controls and code-behind (you can't really remodel your view without remodeling the whole code that deals with it). And the point of the question is pretty much "how to make it otherwise".
The entire WebForm, including the Code Behind, would be the View, the way I envision it.
If the latter, I'd rather not spray odd MVC bits in an app that already consists of bits and pieces strewn together with barely any rhyme or reason.
Then I don't get what you're looking for.
It depends, if you're the new owner, settle in, create a data layer, and start implementing sanity.
If it's not yours, and you're just a guest, make necessary changes and attempt to minimize your footprint and follow the existing style. You may not like it, but it will make it easier on your coworkers.
If it's brand new work, have the ui talk to a logic layer and completely abstract the ui from the data, even if it's a double assignment. It will make migrating to mvc later much easier. (This only applies if you think it will ever change though. )
As for the refresh thing, jquery replace a container?
I worked with webforms for an interview project, if search works you might be able to find me talking about it (I think I created a thread asking if there was any way of not making it terrible, if not, I replied to a thread on the subject asking the same)
It's terrible, everyone has different opinions on how to make it work because no one can find a good way to make it work, only a way that works for them. your best bet is probably to reinvent MVC as people have mentioned, but I would be tempted to just use MVC where possible were I in your situation. The bits where it's easiest to blow everything up in interesting ways are handled by the framework with MVC, and there's an awful lot of code you have to write if you don't use it
I really don't like WebForms. I think it's a crutch for Visual Basic form-monkeys which majorly slows you down once you actually try doing something instead of just cobbling things together.
Googled "Visual Basic monkey". Wasn't disappointed.
Serious answer, at this point WebForms is THE way to quickly slap together a simple web app for internal use. If you're dragging around data grids and buttons in web designer (and not changing "button1"-style names), you know you got the right tool for the job. If you start thinking about patterns and code organization, you should probably switch to MVC.
That said, in a purely legacy maintenance mode, use whatever pattern is already in place.
The correct way to maintain WebForms is to take the folder the code and forms are in, move it to the recycle bin, empty it, then tell your boss you can't find the source code for the older project. Since hardly anyone who uses that crap uses version control of any kind (or if they do, they use SourceUnsafe, which might as well be the same thing), it'll will probably work.
Actually, on second thought, take the whole computer and put it in the real recycle bin. It may be the only way to save your sanity.