7

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

  • 9
    Big ball of mud? – Caleth Oct 6 '16 at 20:56
  • From what I've seen most people using VB to connect to a DBMS still have no formal training and little experience. – david25272 Oct 6 '16 at 21:01
  • 7
    "By developing an application in VB.NET we are implicitly using the MVP pattern"??? I doubt that (or I am misunderstanding you). Using the designer and writing code directly into a form class does not work really different from VB6. To use MVP in VB.NET, one has to write a form-independent presenter class, put all the presentation logic there, and create an interface for the form (="view") class where the presenter talks only to the form using that interface. That is quite the opposite of having MVP implicitly. – Doc Brown Oct 6 '16 at 21:48
10

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.

  • Actually, MS did call it Event Driven Programming. They really took the messaging part of OOP to heart, while neglecting the rest of it for years. – RubberDuck Oct 7 '16 at 0:26
  • @RubberDuck, yet despite lacking all those other nasty features of OO, such as overloading and inheritance, VB apps still all-too-often ended up as unreadable "balls of mud"... – David Arno Oct 7 '16 at 12:15
  • 3
    @David Arno, I know of no language that does not go to mud in the wrong hands. I've encountered and had to maintain mud-balls of C++ and Java. VB is a victim of its success, in terms of how wide an audience it reached. Everybody and their pet cats got into programming during the rise of home computers way back in the late 70's thru the late 90's, and it was the various flavors of BASIC that gave them their start; and then VB leveraged that and rocketed. That's how it ended up with more than its fair share of rubes. – rskar Oct 7 '16 at 20:45
  • 2
    @David Arno, Just acknowledge that VB was a productive language, even in its now obsoleted VB6 form, as evidenced by how many businesses used it profitably, and still use it! C# design drew from the VB experience as well as Java - that's why it has properties rather than going with getters and setters, and that events are part of the language rather than going with extending an 'Observables' framework. – rskar Oct 7 '16 at 20:46
  • 1
    @David Arno, Yet I doubt that C# suffers from having these niceties, or that Java is somehow a tad muddier for lacking that. Language features can be of great help, yes. But overall, mud-balls are more an issue of discipline and professionalism. – rskar Oct 7 '16 at 20:46
6

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.

  • 3
    Your claims about most desirable isn't unique to MS platforms. It's true about all devset. Sturgeon'so law. – whatsisname Oct 7 '16 at 0:36
  • @whatsisname I'm sure it is. I've just seen more MS stack than others. – RubberDuck Oct 7 '16 at 1:04
2

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.

1

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

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.