Qual era il modello di progettazione di VB (prima di .NET)

Question

Qual era il modello di progettazione di VB (prima di .NET)

#1 da (9 voti)
#2 da (5 voti)
#3 da (2 voti)
#4 da (2 voti)

6

Negli ultimi anni abbiamo ascoltato ripetutamente su MVC, MVP e MVVM.

Sviluppando un'applicazione in VB.NET utilizziamo implicitamente il modello MVP (con i moduli di Windows).

Tuttavia, per almeno due decenni, milioni di sviluppatori hanno utilizzato versioni di VB da VB1 a VB6 senza avere un minimo indizio su MVC, MVP, MVVP (non ne hanno nemmeno sentito parlare).

Si trattava semplicemente di trascinare pulsanti, caselle di testo e così via in un modulo et voilá ! L'applicazione è in esecuzione.

Ho due domande:

1) qual è stato il modello di progettazione utilizzato dalle versioni di VB precedenti a .NET?

2) Sapendo che MVP è utilizzato con i moduli di Windows, MVVM con WPF e MVC con ASP.NET, possiamo cambiare le coppie "pattern = > use case".

In altre parole, invece di:

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

Possiamo avere i seguenti scenari:

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

O una qualsiasi delle 9 coppie possibili (oltre le 3 già conosciute)?

In caso negativo, perché?

Grazie

design-patterns visual-basic-6

posta David16 06.10.2016 - 22:34

fonte

4 risposte

Leggi altre domande sui tag design-patterns visual-basic-6

POST e PUT richieste - è solo la convenzione? Sto facendo TDD errato quando più test possono fallire per lo stesso motivo?

score 9 · Answer 1

Early VB supportava alcuni concetti orientati agli oggetti, ma non tutti. La mancanza di ereditarietà, polimorfismo, sovraccarico dell'operatore, ecc. Impedisce l'uso di schemi OOP su quella piattaforma. Inoltre, negli anni '90 MVVM non era così moderno come oggi.

VB aveva una GUI e un modello di eventi davvero carini che hanno reso facile la creazione di applicazioni di tipo "Windows Form". Altre piattaforme, non così tanto.

Il nucleo di questo ruotava attorno agli eventi. Si potrebbe chiamarlo Programmazione guidata dagli eventi. Trascina un pulsante su un modulo, aggiungi alcuni gestori di eventi come Click() and DoubleClick() . Metti un po 'di codice in questi gestori di eventi e chiamalo un giorno.

Si poteva scrivere codice senza eventi, ma la mancanza di un vero supporto OOP di solito significava creare subroutine o moduli in cui questo codice sarebbe vissuto. Questo alla fine ha anche prestato solo un sacco di file con codice e un'applicazione monolitica.

score 5 · Answer 2

Ho intenzione di mettere questo semplice e semplice per te.

La maggior parte degli sviluppatori di VB6 sono molto simili agli sviluppatori di più VB.Net Winforms, che a loro volta sono simili alla maggior parte degli sviluppatori di C # WPF. Essi accumulano un sacco di codici duplicati nel codice sottostante.

Gli smart , che siano VB6, VB.Net o C # dev, useranno una qualche forma di architettura Model-View-Controller. MVVM, MVC e MVP sono solo diverse varianti dello stesso schema di base. È un pattern in circolazione dagli anni '70 e nulla su VB6 ti impedisce di usarlo. È un PITA reale, ma ho usato il pattern MVP con Access VBA.

Suppongo di rispondere concisamente alla tua domanda:

VB6 si presta al meglio al pattern MVP.

score 2 · Answer 3

Sì, puoi cambiare gli scenari. MVVM , MVC , MVP sono pattern e non si attaccano ai framework.

I pattern possono essere usati con altri framework.

Ad esempio, MVVM può essere implementato per Windows Form.
Windows Form ha anche data-binding , non così potente come in WPF , ma è possibile creare ViewModels e dati e comportamenti possono essere "limitati" alla vista.

Anche le modifiche funzionano in altro modo.
Basta trascinare il pulsante e la casella di testo sul designer XAML , fare doppio clic sul pulsante che genera _Button_Click gestore, quindi scrivere il codice

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

E, naturalmente, ricorda di impostare Option Strict in Off :)

score 2 · Answer 4

Direi che un'applicazione VB6 "ben scritta" ha utilizzato i metodi "classici" OOP. Ad esempio, in un'app collegata a un database SQL, verranno create delle classi per abbinare le entità.

Ci sarebbero proprietà che rappresentano campi, variabili private che le proprietà incapsulano e metodi che possono essere pubblici o privati a seconda dell'accesso che si desidera da altri moduli. La maggior parte delle classi dovrebbe avere una sorta di routine di recupero, inserimento, aggiornamento ... e possibilmente una cancellazione. Queste routine dovrebbero richiamare proc memorizzate basate su parametri e qualsiasi routine di recupero restituirebbe un recordset ADO alla vista / modulo chiamante che può quindi essere "vincolato" (nel senso più stretto della parola) al controllo (come un listview, menu a discesa, griglia, ecc.)

I moduli effettivi dovrebbero solo visualizzare i controlli e gestire lo stato di visualizzazione (in modalità Modifica, In modalità Aggiungi ecc.) e generare eventi (clic sui pulsanti, selezione di pulsanti di opzione ecc.) che a loro volta chiamano metodi in una classe o modulo. La gestione degli errori dovrebbe essere implementata correttamente (On Error Resume Next è un enorme bug-bear dei miei)

Non ci dovrebbero essere chiamate di database in nessuno dei moduli, e qualsiasi SQL inline è un grande no-no. Tutte le variabili dovrebbero essere strongmente tipizzate (puoi far sì che il compilatore insista su di essa) e i metodi dovrebbero essere privati o pubblici dove necessario.

Era / è possibile creare app ben strutturate e manutenibili in VB6, ho lavorato con esso fin da VB4, e devo ancora immergermi in esso di volta in volta.

Ho visto alcuni veramente pazzi, quasi impossibili da gestire e eseguire il debug del codice VB6, ma di nuovo l'ho visto anche in VB.Net e C #.

VB6 NON fa "forzare" il codice errato, ma ha reso più facile per i programmatori sbagliati ottenere qualcosa lavorando. Se MS non avesse permesso "On Error Resume Next" e avesse rimosso l'opzione per ignorare Option Explicit, le cose sarebbero andate molto meglio subito.