проверки в MVC / MVP

Question

Я новичок в MVC / MVP и изучаю его, создав приложение Winform.

Я до некоторой степени создал Модели, Докладчики и Представления ... Теперь, куда подходят мои проверки.

Я думаю, что первоначальная проверка типа данных (как и только числа в поле Возраст) должна быть сделана в виде.Принимая во внимание, что другие проверки (например, возраст не превышает 200) должны выполняться моделью.

Что касается проверки типа данных, мое представление предоставляет значения в виде свойств

public int? Age 
{ 
    get 
    { 
        int val; 
        if (Int32.TryParse(TbxAge.Text, out val))
        { 
            return val; 
        } 
        return null; 
    } 
    set 
    { 
        TbxAge.Text = value; 
    } 
} 

Я могу выполнить проверку отдельно,но как мне сообщить докладчику, что проверка еще не завершена, когда он пытается получить доступ к свойству Age?В частности, когда поле является необязательным.

Хорошо ли создавать исключение для проверки, но тогда докладчик должен перехватывать его в каждой точке.

Правильно ли мое понимание или я что-то упустил.

Обновление (для ясности): В этом простом случае, когда поле возраста является необязательным, что делать, если пользователь набрал свое имя вместо числа. Я не могу передать значение NULL, так как это означает, что поле было оставлено пользователем пустым. Итак, как мне сообщить докладчику, что введены неверные данные ...

Answer 1

Исходя из MVP (я считаю, что это более подходит для WinForms), ответ на ваш вопрос является дискуссионным. Однако ключом к моему пониманию было то, что в любое время вы сможете изменить свое мнение. То есть я должен иметь возможность предоставить новое представление WinForms для отображения вашего приложения или подключить его к интерфейсу ASP.NET MVC.

Как только вы осознаете это, проверка становится явной. Само приложение (бизнес-логика) должно генерировать исключения, обрабатывать ошибки и так далее. Логика интерфейса должна быть тупой. Другими словами, для представления WinForms вы должны убедиться, что поле не пустое и т. Д. Многие свойства для элементов управления позволяют это - панель свойств Visual Studio. Проверка правильности написания кода в графическом интерфейсе для тех, кто выбрасывает исключения, является большой нет, нет. Если бы у вас была проверка как для вида, так и для модели, вы бы дублировали код - все, что вам нужно, - это простая проверка, такая как, например, не пустые элементы управления. Пусть фактическое приложение само выполняет фактическую проверку.

Представьте себе, если бы я переключил ваш взгляд на интерфейс ASP.NET MVC. Я бы не сказал, что элементы управления, и, следовательно, потребуется некоторая форма сценариев на стороне клиента. Я хочу сказать, что единственный код, который вам нужно написать, - это представления, то есть не пытайтесь обобщать валидацию пользовательского интерфейса между представлениями, так как это противоречит цели разделения ваших интересов.

В вашем основном приложении должна быть вся логика. Специальная логика представления (свойства WinForms, Javascript и т. Д.) Должна быть уникальной для каждого представления. На мой взгляд, иметь свойства и интерфейсы, которые должны проверять каждое представление, неправильно.

Answer 2

Если ваше «представление отображает значения как свойства», я подозреваю, что вы что-то упустили.Принципиальное различие между MVP / MVC и некоторыми другими шаблонами развязки пользовательского интерфейса заключается в том, что они включают модель, которая предназначена в качестве основного контейнера для данных, совместно используемых представлением и докладчиком или контроллером.

Если выИспользуя модель в качестве контейнера данных, ответственность за проверку становится вполне ясной.Поскольку только докладчик (или контроллер) фактически делает что-либо, кроме отображения данных, именно он отвечает за проверку того, что данные находятся в приемлемом состоянии для операции, которую они собираются выполнить.

Добавление визуальногоИндикаторы проблем проверки данных в форме / окне редактора во время редактирования, безусловно, приятно иметь.Однако его следует считать более или менее эквивалентным представлению «конфетки глаз», и его следует рассматривать как дополнение к реальной логике проверки (даже если оно основано на общих метаданных или коде).Презентатор (или контроллер) должен оставаться истинным авторитетом для достоверности данных, и его код проверки не должен размещаться в представлении.

Answer 3

Я полагаю, что проверка представления важна только в javascript, так как представление не запускает какой-либо код в посте, а только контроллер.

Но я бы также не стал доверять проверке javascript, поскольку злоумышленник мог ее обойтиили для невежественного пользователя может быть отключен JS, поэтому повторите любую проверку JS в серверном коде в контроллере.

Хотя представление может иметь средства для отображения любых ошибок.