In the process of studying the various options for organizing code for the user interface (MVC, MVP, MVVM, MVPVM, and what they call these names), I am a bit confused.

Therefore, as usual, something was done using intermediate interfaces.

And now I ask you to suggest whether this version corresponds to any long-known abbreviation, and where among these three classes and two interfaces are M, V, C, P, VM or their parts and the mixture?

So, approximately, I have the code for a simplified search form:

1) The interface, which indicates which controls and which basic type (basic buttons, text fields, etc.) should be presented in this part of the interface:

public interface IView_SearchForm { TextField getQueryField(); Button getSubmitButton(); TextField getResultsField(); }

2) The implementation of this part of the interface (with design buttons, text fields, etc., which inherit from the base, specified in the interface):

 public class View_SearchForm_v11 implements IView_SearchForm { @FXML private YetAnotherTextField txtField1; @Override public TextField getQueryField() { return txtField1; } @FXML private SuperPuperButton button1; @Override public Button getSubmitButton() {return button1;} @FXML private YetAnotherTextField txtField2; @Override public TextField getResultsField() { return txtField2; } }

and the corresponding .fxml:

 <?xml version="1.0" encoding="UTF-8"?> <?import javafx.scene.layout.*?> <VBox fx:controller="View_SearchForm_v11"> <YetAnotherTextField fx:id="txtField1"/> <SuperPuperButton fx:id="button1" text="Submit"/> <YetAnotherTextField fx:id="txtField2"/> </VBox>

3) Interface, which indicates what data and methods should be implemented in the model related to this part of the interface:

 public interface IModelAndMethods_SearchForm { StringProperty getQueryProperty(); StringProperty getResultsProperty(); void startSearch(); }

4) Implementation of the data model and methods:

 public class ModelAndMethods_SearchForm_v45 implements IModelAndMethods_SearchForm { final private StringProperty queryProperty = new SimpleStringProperty(); @Override public StringProperty getQueryProperty() {return queryProperty;} final private StringProperty resultsProperty = new SimpleStringProperty(); @Override public StringProperty getResultsProperty() {return resultsProperty;} void startSearch() { resultsProperty.set(querySomeOne(queryProperty.get())); } }

5) Associating the interface with data and methods (all the supporting work got into the base class BinderBase<IView,IModelAndMethods> ):

 public class Binder_SearchForm extends BinderBase<IView_SearchForm, IModelAndMethods_SearchForm> { @Override protected void bind() { IView_SearchForm v = getView(); IModelAndMethods_SearchForm mm = getModelAndMethods(); addBidirectionalBinding(v.getQueryField().textProperty(), mm.getQueryProperty()); addBidirectionalBinding(v.getResultsField().textProperty(), mm.getResultsProperty()); addAction(v.getSubmitButton(), event -> mm.startSearch()); } }

A typical download of all this looks like this:

 @Override public void start(Stage primaryStage) throws Exception { ModelAndMethods_SearchForm_v45 modelAndMethods = new ModelAndMethods_SearchForm_v45(); Scene scene = Loader.loadAsScene( View_SearchForm_v11.class, modelAndMethods, Binder_SearchForm.class); primaryStage.setScene(scene); primaryStage.show(); }

    1 answer 1

    This design pattern is called VELOSIPED.

    In order:

    • There is no M. in this code.

    In the MVP, MVVM, MVPVM patterns, it is assumed that M (Model, Model) is the data model for the entire application. In the code above, this model is not shown.

    • There is a VM from MVVM.

    VM (ViewModel, View Model) in the MVVM template is a pretty smart model, containing both data and logic. The ModelAndMethods_* class from the code above is similar to such a Model.

    And this is definitely not a VM from the MVPVM template (Bill Kratochvil, 2011), where the ViewModel is stupid, and the Representative performs all the work (Presenter).

    • Where is V?

    V (View, View) in the MVVM template is smart enough to subscribe to View Model events on its own. To do this, all types of bindings are fully implemented in WPF's XAML.

    In FXML, two-way binding (via #{} ) has not yet been implemented. Therefore, V of MVVM represent three files: .fxml-file and two classes - View_* and Binder_* .

    On the other hand, if we consider the MVP pattern with the Passive View (Passive View), then V is only two files: the .fxml file and the View_* class.

    • Here is P.

    By P (Presenter, Representative) in the MVP pattern is meant the code that binds View (V) and Model (M). This is exactly what the Binder_* class Binder_* .

    Thus, we can assume that the presented code, when the Application Model (M) is added to it, will become a variant of MVVM, in which V is divided into P and passive-V.

    • MVC pattern.

    The MVC pattern has different interpretations.

    In the classic version (also referred to as SmallTalk MVC) Representation (V) itself climbs into the Model, unattended with C (Controller). This is what distinguishes it from MVP, where the Presentation (V) is associated with the Model only by the Representative (Presenter).

    However, the name "MVC" in such a narrow sense is only used when describing such patterns as MVP.

    Usually, MVC is interpreted much more widely - as breaking a certain monolith into parts (for example, the same Spring MVC is not at all the same as SmallTalk MVC).

    In this broad sense, the above code is a variant of MVC. Where class IModelAndMethods_* is M, class View_* is V, and class Binder_* is C.

    PS: Later the Hot Folder Controller (C) will be added, which will work with the Application Model (M), but not with P or V. A bunch of CM-VM-PV will turn out ...