What was the design pattern of VB (before .NET)

Question

In recent years all we have heard over and over about MVC, MVP and MVVM.

By developing an application in VB.NET we are implicitly using the MVP pattern (with windows forms).

However, along at least two decades, millions of developers used versions of VB from VB1 to VB6 not having a minimal clue about MVC, MVP, MVVP (they don't even heard about that).

It was just drag and drop buttons, text boxes and so forth to a form et voilá! The application ran.

I have two questions:

1) what was the design pattern used by versions of VB prior to .NET?

2) Knowing that MVP is used with windows forms, MVVM with WPF and MVC with ASP.NET, can we change the pairs "pattern => use case".

In other words, instead of:

MVP  => Windows Forms
MVVM => WPF
MVC  => ASP.NET

Can we have the following scenarios:

MVP  => WPF
MVVM => ASP.NET
MVC  => Windows Forms

Or any one of the 9 possible pairs (beyond the 3 already known)?

If not, why?

Thank you

Answer 1

Early VB supported some object oriented concepts but not all. Lack of inheritance, polymorphism, operator overloading, etc. hinders the use of OOP patterns on that platform. Plus, in the 90s MVVM wasn't as hip as it is today.

VB had a really nice GUI and event model which made it easy to create a "Windows Form" type applications. Other platforms, not so much.

The core of this revolved around events. One could call it Event Driven Programming. Drag a button onto a form, add a few event handlers like Click() and DoubleClick(). Put some code in those event handlers and call it a day.

One could write code without events, but the lack of true OOP support usually meant creating Subroutines or Modules where this code would live. This also lent itself just a lot of files with code and a monolithic application in the end.

Answer 2

I'm going to put this plain and simple for you.

Most VB6 devs are very much akin to most VB.Net Winforms devs, which in turn are akin to most C# WPF devs. They pile figurative shit loads of duplicate code into the code behind.

The smart ones, whether a VB6, VB.Net, or a C# dev, will use some form of Model-View-Controller architecture. MVVM, MVC, and MVP are all just different variations of the same basic pattern. Its a pattern that's been around since the 70's and nothing about VB6 prevents you from using it. It's a royal PITA, but I've used the MVP pattern with Access VBA.

---

I suppose to answer your question concisely:

VB6 best lends itself to the MVP pattern.

Answer 3

I would say a 'well written' VB6 application used 'classic' OOP methods. For example, in an app connected to a SQL database, there would be classes created to match the entities.

There would be properties representing fields, private variables which the properties encapsulate, and methods that can be public or private depending on the access you want from other modules. Most classes should have some sort of Fetch, Insert, Update routine(s)... and possibly a Delete. These routines should all call parameter based stored procs - and any Fetch routine would return an ADO recordset to the calling view / module which can then be 'bound' (in the loosest sense of the word) to the control (such as a listview, dropdown, grid etc).

The actual forms should just display the controls and handle view state (in Edit Mode, In Add mode etc) and fire events (button clicks, radio button selection etc) which in turn call methods in a class or module. Error handling should be implemented properly (On Error Resume Next is a massive bug-bear of mine)

There should be no database calls in any of the forms, and any inline SQL is a big no-no. All variables should be strongly typed (you can make the compiler insist on it) and methods should be private or public where necessary.

It was/is possible to create well structured and maintainable apps in VB6, I've been working with it since VB4, and I still have to dip into it from time to time.

I've seen some really crazy, almost impossible to maintain and debug VB6 code, but then again I've seen it in VB.Net and C# too.

VB6 DOES NOT 'force' bad code, it just made it easier for bad coders to get something working. If MS had not allowed 'On Error Resume Next' and had removed the option to disregard Option Explicit things would have been a lot better straight away.

Answer 4

Yes you can change scenarios. MVVM, MVC, MVP are patterns and doesn't stick to the frameworks.

Patterns can be used with other frameworks.

For example MVVM can be implemented for Windows Forms.
Windows Forms have data-binding too, not so powerful as in WPF, but ViewModels can be created and data and behavior can be "bounded" to the view.

Changes works in other way too.
Just drag button and textbox to the XAML designer, double click button which generate _Button_Click handler, then write your code

TextBox.Text = GetTotalSum("Select Decimal FROM Table WHERE name = " & stringname & ")

And of course remember set Option Strict to Off :)