Discussion of MVC/MVP/MVVM

Mathieu Guindon

Apr 22, 2019 15:40

@FreeMan that is literally this question:

19

Q: Are there disadvantages in putting code into Userforms instead of modules?

Are there disadvantages in putting code into a VBA Userform instead of into a "normal" module? This might be a simple question but I have not found a conclusive answer to it while searching the web and stackoverflow. Background: I am developing a Front-End Application of a database in Excel-VB...

Offloading code-behind to another module is basically taking a situation where you have a form doing all the work and turning it into a situation where you have a module that knows way too much about how a particular form is made.

i.e. that module wants to be the form's code-behind

mansellan

@this Not true. ODE has a plugin, at least for Excel. It is very, very poor however.

this

so it actually exports/imports Excel documents?

Didn't know

mansellan

@this Ah no, just code modules iirc

this

With Access, you can export the forms and reports. I am not aware of any other hosts providing that functionality.

mansellan

me either

and the ODE plugin looks like it was thrown together by an intern in an afternoon.

this

Apr 22, 2019 15:50

i'm sure ODE just wraps the VBComponent.Export and VBComponents.Import

mansellan

it has some toolwindows to show checkout status, and links into the VSS provider

but yes, essentially that's all it's doing

Son Goku ssj4

Apr 22, 2019 16:17

@MathieuGuindon Okay, so A) I'll rename modules from now by Refactoring.

BUT B) this is happening in all fields. And I work heavily with .Tag property. It's the same there.

Mathieu Guindon

@SonGokussj4 I'll try setting up a breakpoint in the AC service and see if it's involved in that delay; it shouldn't be though.

Son Goku ssj4

@MathieuGuindon Do your magic. :-) I'm lost in this sentence.

Mathieu Guindon

@SonGokussj4 if you go to autocompletion settings and disable it (the "master" checkbox at the top), do you still get that backspace delay in the properties toolwindow?

Son Goku ssj4

Apr 22, 2019 16:34

@MathieuGuindon yes. I even tried to exit excel and start it again. Autocomplete is disabled

@MathieuGuindon Interestingly enough (and that's why I asked for someone else to try), it's happening even when I disabled "startup/loaded" of Rubberduck from Add-is / Add-in Manager

So it seems it's my thing on the local computer. I'll try it tomorrow at work.

Mathieu Guindon

Apr 22, 2019 16:49

That's good news then! Not a RD bug! =)

Son Goku ssj4

Weird and weirder.
a) tried it on my ntb (office 365) - the same
b) tried it on my local pc (office 2019) and opened entirely new file with only one form. The same problem

I suppose it's not RD :-) Or the installation of RD did something to my office but this I highly doubt... I will look for this on google.

Yeah. Glad it's not RD bug :-)

FreeMan

Apr 22, 2019 17:35

@MathieuGuindon I've read that before. I actually starred it. I'd forgotten all about it. hangs head in shame and shows self to the door

FreeMan

Apr 22, 2019 17:49

So the key to the code-behind is here:

Private Type TView
    Model As FilterModel    '<-------
    IsCancelled As Boolean
End Type

The model is actually referenced in the code behind, and methods in the model (IsValid) may be referenced in the code behind, but all of the gubbins of the model could change, and so long as it exposes an IsValid the form itself won't know or care.

this

yep

the forms should basically only write/read to/from the model and when done, give it back.

Keep in mind, that's good as long you aren't binding

With a bound form, MVP no longer make sense.

While you can create unbound forms in Access and therefore use MVP pattern, if you are doing this all the time, one starts to ask why even bother with Access? Might as well write it in C# instead.

FreeMan

In the case where there are various and sundry options on a form, some of which enable other options, checking the options and setting the appropriate .Enabled flags would belong in the Model in something like a Validate method that would be called by each checkbox the way the TextBox1_Change method in that example is - Assign the form field to the corresponding Model property, then Validate

light bulb glows slightly brighter

this

yeppas!

the whole point of MV* patterns is to separate the data (the model) from the UI stuff

if you're doing If SomeForm.SomeCheckbox Then in some other module, you're doing it wrong™.

You want to have If SomeModel.IsChecked Then instead because then you can just pass a model with whatever data it needs to have, without caring how the model was actually made.

FreeMan

Apr 22, 2019 18:05

the bell of understanding rings faintly

Now, if all of this will stick whilst I get distracted by something else urgent that's about to hit...

this

To keep this simple, when you're wondering if it's the right thing to do - simply ask yourself: "must I open a form in order to run this code?"

if the answer is yes, then you know that this code is too tightly coupled to the form.

Private Sub DoIt() : OpenMyFormToCollectInput : <rest of doing stuff> : End Sub <= big smell.

You want this instead:

Private Sub DoIt(SomeModel As Something) : <rest of doing stuff> End Sub

FreeMan

The model is just the data shown in the fields on the form. It's not necessarily "data" as in something coming from or going to a DB, it could simply be the configuration information for how to run this report you're about to run.

this

yep.

FreeMan

Not going to ask how to apply (or not, or modify) this to bound forms in Access - at the moment, I don't really have any, and I'm starting to grasp the concept - I don't want to throw in other stuff to muddy the waters yet.

this

don't worry, I don't have a good answer for bound forms in Access.

only few rough ideas but I've yet to put it to test

#SoMuchToDoSoLittleTime

FreeMan

Apr 22, 2019 18:16

The model does have to mirror the form, though, right? It's got to hold all the data presented on the form and has to know what to do with each bit of it, so they're tightly coupled. It's just that the form itself doesn't care how the data is handled. It's kinda the mainframe dumb terminal of the GUI world - Put this here & show the user, then let me know when he's done something with it, I'll take it from there.

this

at least the data that's relevant to the process.

but yeah

it's rare but there can be "data" that aren't part of model -- an example would be some logic to enable/disable a control on the form based on the selection on another control.

the model doesn't need to "know" about that enabled/disabled; the two controls' value will be most likely copied to the model and that's usually enough

Mathieu Guindon

@FreeMan the way I see it it's the form/view that's "mirrorring" the model - its job being quite literally to provide an interface for the user (ergo, user interface) to interact with the model

IOW a form is just one of many possible ways for the rest of the code to collect input or produce output, and the rest of the code shouldn't have to pop any actual dialog to be able to work.

Just like Battleship doesn't need any worksheet UI to be playable - as long as the controller can talk to something that can act as an IGridView, it's happy to talk to and interact with it. No discrimination!

FreeMan

Apr 22, 2019 18:37

@MathieuGuindon Makes sense. Us old-skool guys, though, tend to think in the "Form->Action" methodology, and in that respect, my way made sense to me.

I definitely get the point, though.

I guess the model is "Here's the data & actions that a user would need to see". While the form is "Here's a way of looking at (some of) the data in the model and a way of invoking (some of) the actions". right?

this

IDK. When you click the Do It button, you should be handing off the model to some other class that is responsible for well, doing it.

Mathieu Guindon

^

this

so the model itself really doesn't have "actions"

actions are represented in classes and those classes need the data from model.

Mathieu Guindon

The model is just data and the knowledge of what valid/usable data looks like

Actions belong on whatever component knows about both the view and the model - whether you call that a presenter, a controller, or whatever else

this

I was thinking about that -- a controller would directly execute the action, whereas a presenter would simply return the result, no?

FreeMan

Apr 22, 2019 18:43

I was thinking of actions = IsValid, or Validate, or EnableProperControls, more than RunTheReport or ImportTheData

this

those are more "validation" (two of the name has it in the name...) ;-)

and even so, whether model should do validations is debatable (some will argue it's view's job to validate, etc. etc.)

FreeMan

reviews list, agrees with @this, those were the "actions" I was thinking of. I realize that wasn't clear from what I typed

If the View is validating data, isn't that overstepping its bounds of "Show stuff to the user (UI)"?

this

No no no no, not data

validating what you can do on the form itself.

FreeMan

ah, validate option combinations

this

yeah

FreeMan

Apr 22, 2019 18:46

ok - fine-ish line

this

if you needed to validate against some other data, I would argue that it's model's thing.

yes, not a hard and fast rule.

FreeMan

I think I'm getting it.

With emphasis on think.

Based on earlier conversation, Application.SaveAsText will export my Access code behind, no matter how MVP compliant it is or isn't, and somewhere, there are some other commands to export/import other code modules.

this

it's actually the same command (if you're sticking to Access' OM)

but yes

FreeMan

Step 1 is to write that up so I can get the code into git. Step 2 is to properly MV[C|P] a new interface for the new stuff I need to do. Step 3 is to refactor old stuff into a proper MV[C|P] model

this

but I think the command Application.SaveAsText acModule, "some module", "some path" is just a thin wrapper over VBComponent.Export

FreeMan

Apr 22, 2019 18:50

Only difference between MVC & MVP is whether you chose to have a "Controller" or a "Presenter" and the main difference between those is spelling. Correct?

this

whereas Application.SaveAsText acForm, "some form", "some path" would be its own thing.

well, no

FreeMan

sigh...

notes difference between acModule and acForm

this

MVC is more commonly used in a server-client interaction --- a web application for example

since controller is more "active" in deciding what to do next

whereas presenter, in my mind is more passive - it only presents a form for user to interact then provide the result but does nothing further. It's up to the whoever activated the presenter to do something about it.

FreeMan

light bulb of understanding flickers...

I though the View was what you just described as the Presenter

this

take the above with a huge grain of salt. I don't think everyone has a crystal idea of what MVC, MVP and MVVM should be.

no

presenter basically instantiates the view, sets it up with the model, then show it

(hence, presenting)

FreeMan

Apr 22, 2019 18:53

@this had to read that twice to recognize "everyone", not "anyone"

this

I say that because in my reading, many people are just as fuzzy in describing the difference between the 3 patterns

it does not help that RD itself has to use both MVP and MVVM patterns. #FunTimes

Because WinForms can only do MVP whereas WPF is better with MVVM. Note that MVC doesn't apply here because we aren't a web app.

VBA Rubberducking

Participants