Где осуществлять валидацию пользовательского ввода в архитектуре MVC?

Question

[Karas89]

Всем привет. Пишу настольную программу на Java c гуи на JavaFX. Решил изучить шаблоны ООП и, в частности, подход MVC. Данные сохраняются в файловую реляционную бд. Валидация данных в плане соответствия реляционной модели - понятно, в классе модели. А где нужно, "по уму", закладывать проверки, что в числовое поле введено число? Где фильтруются sql-инъекции, HTML-разметку и прочие грязные хаки?
В гугле куча примеров ASP.NET MVC или веб-приложения, на пхп, например. Там тоже все мне не очень ясно. В случае, если у нас статическая HTML страница, то все контроллеры и модели - на стороне сервера, а что в случае, если у нас на фронтенде много JS кода с логикой? Как распределена ответственность между частями системы в рамках архитектуры MVC в случае с толстым клиентом?

Answer 1

[Maa-Kut]

А где нужно, "по уму", закладывать проверки, что в числовое поле введено число? Где фильтруются sql-инъекции, HTML-разметку и прочие грязные хаки?

По идее, все вышеперечисленное относится к бизнес-правилам и, соответственно, лежит в моделях. Т.е. контроллер, получив некий ввод от пользователя, отдает эти данные модели (мол, "проверь" или "попытайся сохранить"), а модель либо говорит, что все хорошо, либо возвращает список ошибок, не дающих данные обработать.

Как распределена ответственность между частями системы в рамках архитектуры MVC в случае с толстым клиентом?

Толстый JS-клиент можно сам по себе рассматривать как MV*-приложение. Серверная часть в этом случае становится моделью. При этом часть функций модели (скажем, некая базовая валидация) может быть реализована и на стороне JS; в конце концов, никто не говорит, что модель не может состоять из нескольких слоев.

Comments

[Karas89]

Спасибо за ответ. Мне просто не дает покоя такая вещь, как "защитное программирование" (не уверен, что термин корректный, видел в книге переводной, но, как известно, переводы не всегда качественные). Ввод от View передается модели через контроллер, так? Правильно ли я полагаю, что талантливые хацкеры могут опрокинуть приложение по пути к модели? Если да, то тут вроде логично всякие инъекции и переполнения буфера фильтровать между view и контроллером.

[Maa-Kut]

Karas89: Именно поэтому контроллер должен быть по возможности простым: если он сам в БД не ходит, то и никакими инъекциями его уязвить не получится. Плюс грамотная настройка самого веб-приложения, чтобы оно имело ровно столько полномочий, сколько нужно. Плюс всякие дополнительные средства вроде .NET-ного Code Access Security.

[Сергей Протько]

Maa-Kut:

Толстый JS-клиент можно сам по себе рассматривать как MV*-приложение. Серверная часть в этом случае становится моделью.

извините, но с каких пор "база данных" это модель? Ну мол с точки зрения JS клиента сервер это лишь способ синхронизации состояния с другими клиентами. А как быть с P2P приложениями? у них не может быть модели? Или приложения, которые хранят все данные исключительно на клиенте и не имеют сервера как такового?

База данных - это модель данных приложения. Приложение может возвращать другое представление этих данных и для UI именно эти данные будут являться "моделью данных" Мол:

[ View -> Controller ] -> Application -> Database -> Application -> [ DTO -> Controller -> View ]

Квадратными скобочками тут отмечена зона ответственности MVC.

[Maa-Kut]

Сергей Протько:

извините, но с каких пор "база данных" это модель?

БД - это хранилище, а вопрос сохранения данных тоже закрывается моделью. В смысле, логика взаимодействия с БД - это тоже часть модели.

Ну мол с точки зрения JS клиента сервер это лишь способ синхронизации состояния с другими клиентами.

Не-не-не, такого я тоже не говорил. JS-клиент реализует лишь часть логики, прежде всего, связанной с UI: экраны, переходы между ними, первичная валидация вводимых данных и т.п. Бизнес-логика все равно "живет" на сервере. В конце концов, приложение может иметь и другие UI (Android/iOS-клиенты, например).

Или приложения, которые хранят все данные исключительно на клиенте и не имеют сервера как такового?

Так ведь концепция MVC не накладывает никаких условий на физическое размещение компонентов M, V и C: они, по факту, могут вообще все вместе жить в одном jar/exe-шнике.

[Сергей Протько]

Maa-Kut: если вам эта тема интересна, рекомендую ознакомиться: heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

There should be a one-to-one correspondence between the model and its parts on the one
hand, and the represented world as perceived by the owner of the model on the other hand.
The nodes of a model should therefore represent an identifiable part of the problem.
The nodes of a model should all be on the same problem level, it is confusing and considered
bad form to mix problem-oriented nodes (e.g. calendar appointments) with implementation
details (e.g. paragraphs).

Бизнес-логика все равно "живет" на сервере. В конце концов, приложение может иметь и другие UI (Android/iOS-клиенты, например).

Ну я привел пример - p2p приложение. Огромная сеть распределенных приложений, как такового сервера там нет, вся логика на клиенте.

Более того, на клиенте и сервере может быть в принципе разная логика.

Мне просто не упрощения в духе "сервер это модель", поскольку у приложения на клиенте тоже может быть своя модель, а сервер в этом случае лишь деталь реализации. Я часто слышу фразы в духе "модель это база данных" или "модель это штука которая имеет доступ к базе данных". Это подтакливает разработчиков к толстым контроллерам, вынося бизнес логику в них. А это убивает саму идею разделения ответственности.

[Maa-Kut]

Мне просто не упрощения в духе "сервер это модель", поскольку у приложения на клиенте тоже может быть своя модель, а сервер в этом случае лишь деталь реализации.

Я, в общем-то, и не утверждал, что "модель" и "сервер" - эквивалентные понятия. Если мы берем всю систему целиком (от JS до самых потрохов), то большая часть модели получается реализованной на сервере приложений, но часть ее вполне может жить и на стороне JS.

При этом да, можно реализовать систему так, что JS и серверная часть вообще будут полностью независимы друг от друга; сервер для JS-клиента будет просто некоей внешней системой (возможно, одной из многих).

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

Я часто слышу фразы в духе "модель это база данных" или "модель это штука которая имеет доступ к базе данных".

Во фразах "модель данных" и "модель в MVC" и там и там присутствует слово "модель", что часто приводит к путанице. Я такого не утверждал, выше указал свое видение данного вопроса.

Answer 2

[Сергей Протько]

Давайте размышлять что такое валидация и зачем она нам нужна:

Нам нужно проверять, не нарушаются ли пред-условия для действий или инварианты состояний. Например - пользователь всегда должен иметь email - такие правила можно запихивать на уровне конструктора класса пользователя. Тогда у нас не будет физически возможности "создать" пользователя не указав email. Что бы убедиться что переданная строка email - мы можем опять же завернуть "примитив" в свой тип Email, таким образов сделав подтип строк, который гарантирует нам, что любая штука относящаяся к этому типу будет являться email-ом.

Такие правила как "у пользователя должен быть уникальный email" могут быть проверены только там, где достаточно информации. Например - некий репозиторий пользователей, или DAO. При попытке "сохранить" мы уже делаем проверку. Или мы можем делать это просто повесив ограничение на уникальность на уровне базы данных. Это уже не столь важно.

Различие тут в том, что все это будет вызывать ошибки. То есть мы не сможем вогнать систему в "невалидное состояние" но пользователь не сможет получить список ошибок, которые он совершил вводя какие-то данные. Все что он получит - отдельные ошибки.

То есть если смотреть с позиции пользователя, помимо валидации бизнес правил, нам нужно так же производить валидацию входящих данных. Валидацию данных запроса, на уровне контроллера. Тогда у нас есть все входящие данные и каждый отдельный экшен будет знать что надо проверять. И тогда у нас будет возможность проверить все правила и выдать один список всех проблем с входящими данными.

В простых случаях, когда данные из запроса втупую мэпятся на "модель данных", мы можем проверять уже результат. Но в случае с логикой сложнее CRUD это уже не выйдет. Точнее это уже чуть сложнее. К примеру мы передали несуществующий айдишник связанной сущности. Мы запросим данные, получим нул, и валидатор выдаст нам что-то вроде "Извините, но вот эта штука обязательна к заполнению". А пользователь такой "чтааа? Я ж заполнил!" Вот если бы ему приходило сообщение мол "Выбранная вами штука не существует" - тогда ладно, но подавляющее большинство так не запаривается.

Словом... тут нужно исходить не из "где это делается в MVC" а из "а кому это нужно и какие цели вы приследуете".

Если что, MVC это не все приложение, это лишь способ разделить ответственность. Приложение ничего не должно знать о UI и все. То есть валидация входящих данных вполне может лежать на уровне контроллера поскольку это ему нужно сформировать список ошибок и запихнуть их к полям формы. С другой стороны, часть валидации может происходить вообще вне "MVC", где-то внутри, на уровне модели предметной области.

Нельзя из букв "M", "V" и "C" составить слово вечность. Именно по этой причине MVC как подход для организации GUI уже лет 20 как не используется в чистом виде.