Диалог настроек VBA с использованием MVP - нужна ли мне модель?

Question

Я читал о многих примерах MVP (Model-View-Presenter) и их вариациях (пассивное представление, контролирующее представление), чтобы попытаться сделать мои решения более надежными (и многократно используемыми) в VBA (используя Excel в качестве хост в этом случае). Проблема, которую я обнаружил, - это найти хорошие, простые примеры в VBA, которые не являются излишними для (надеюсь) простых примеров, которые мне нужны.

Я пытаюсь создать диалоговое окно «Настройки», в котором хранится определенная конфигурация на листе (это мой «репозиторий»).

Вот моя основная процедура, запускаемая пользователем:

Private Sub ShowImportSelector()
    Dim importPresenter As DataImportPresenter
    Set importPresenter = New DataImportPresenter

    importPresenter.LoadConfig
    If importPresenter.Show = -1 Then Exit Sub
    importPresenter.SaveConfig

    ' begin processing...
    If (CStr([Settings.SelectedVersion].Value2) = "QQ") Then
       ' ...
    End If

End Sub

Вот мой " Presenter " (здесь я использую имена диапазонов для источника и назначения конфигурации):

Option Explicit

Private m_importForm As FImport

Private Sub Class_Initialize()
    Set m_importForm = New FImport
End Sub

Public Sub LoadConfig()
    m_importForm.SetAvailableVersions "tblVERSION"
    m_importForm.SetAvailableSalesOrgs "tblSALESORG"
    m_importForm.SetAvailableCategories "tblCATEGORY"
    m_importForm.ToolName = "Forecast"
End Sub

Public Sub SaveConfig()
    [Settings.SelectedVersion].Value2 = m_importForm.SelectedVersion
    [Settings.SelectedSalesOrg].Value2 = m_importForm.SelectedSalesOrg
    [Settings.SelectedCategory].Value2 = m_importForm.SelectedCategory
End Sub

Public Function Show() As Integer
    m_importForm.Show vbModal
    Show = m_importForm.Result
End Function

А теперь " View " (форма VBA):

Option Explicit

Private m_selectedVersion As String
Private m_selectedSalesOrg As String
Private m_selectedCategory As String
Private m_toolName As String
Private m_dialogueResult As Long

Public Property Get ToolName() As String
    ToolName = m_toolName
End Property

Public Property Let ToolName(ByVal value As String)
    m_toolName = value
    ToolNameLabel.Caption = value
End Property

Public Property Get Result() As Long
    Result = m_dialogueResult
End Property

Public Property Get SelectedVersion() As String
    SelectedVersion = m_selectedVersion
End Property

Public Property Get SelectedSalesOrg() As String
    SelectedSalesOrg = m_selectedSalesOrg
End Property

Public Property Get SelectedCategory() As String
    SelectedCategory = m_selectedCategory
End Property

Public Sub SetAvailableVersions(ByVal value As String)
    VersionSelector.RowSource = value
End Sub

Public Sub SetAvailableSalesOrgs(ByVal value As String)
    SalesOrgSelector.RowSource = value
End Sub

Public Sub SetAvailableCategories(ByVal value As String)
    CategorySelector.RowSource = value
End Sub

Private Sub SaveSelections()
    m_selectedVersion = VersionSelector.value
    m_selectedSalesOrg = SalesOrgSelector.value
    m_selectedCategory = CategorySelector.value
End Sub

Private Sub CloseButton_Click()
    m_dialogueResult = -1
    Me.Hide
End Sub

Private Sub ImportButton_Click()
    SaveSelections
    m_dialogueResult = 0
    Me.Hide
End Sub

В этот момент я запутался в возможных направлениях, которые я мог бы использовать в плане добавления модели к вышеприведенному - вопрос: нужно ли это даже для этого простого примера?

Answer 1

Архитектура MVP делает более чистый код, но более чистый код не является основной целью MVP; достижение слабой связи , более высокой когезии и тестируемости is.

Если слабосвязанные компоненты и логика, проверяемая модулем, не являются обязательными, то полномасштабный MVP действительно излишним, и показ модели в качестве свойств в представлении определенно достаточно хорош , так как это уже помогает сделать так, чтобы ваш «ведущий» не заботился о контроле формы. Вы рассматриваете форму как объект, о котором она просит, и, прагматично говоря, это вполне может быть всем, что вам нужно. Я бы сделал так, чтобы метод Show возвращал явный Boolean, поскольку он неявно используется как таковой.

С другой стороны, если вы снимаете для развязки и проверки, то извлечение модели из вида будет только первым шагом : тогда вам нужно отделить докладчика от лист, и, возможно, представит некоторый интерфейс ISettingsAdapter, который абстрагирует его, так что если / когда конфигурация должна перейти в базу данных или в какой-либо файл .config, ваш код докладчика не должен изменяться каким-либо образом ... но это требует разработки интерфейсов без учета какой-либо конкретной конкретной реализации , то есть чего-то, что работает без изменений, независимо от того, находятся ли данные на рабочем листе, в каком-то плоском файле или в некоторой таблице базы данных.

MVP требует смены парадигмы: MVP больше не процедурное программирование, это ООП. То, является ли ООП избыточным для ваших нужд, зависит от того, насколько много связей вы готовы прожить, и насколько слабой эта связь делает ваш код перед лицом будущих изменений. Часто достаточно абстракции : использование именованных диапазонов вместо жестко закодированных адресов диапазонов является одним из способов повышения уровня абстракции; скрытие рабочего листа за интерфейсом адаптера, реализованным прокси-классом рабочего листа (что бы вы ни делали, никогда не заставляет модуль рабочего листа реализовывать интерфейс: он будет падать) - это другое - зависит от того, где ваш порог «перебор» есть, но если вы делаете достигаете полной развязки и пишете модульные тесты , никто не сможет обвинить вас в том, что вы перешли за борт: вы просто следуете передовым отраслевым практикам, которые Каждый программист стремится к тому, чтобы улучшить свои навыки и упростить последующее использование этого кода и его переписывание в .NET, будь то VB или C #. Я сомневаюсь, что кто-либо будет утверждать, что полномасштабный MVP является избыточным в .NET / WinForms.