Тех процесс тоньше — количество циклов перезаписи ячейки меньше. Значит нужно больше дополнительного пространства под wear leveling. Тут обоюдоострый меч.
Но в целом всё равно выгоднее.
Если вам в конкретном View удобно пробросить IsAuthenticated в модель — делайте это.
Если в конексте использования, вы понимаете, что IsAuthenticated не уместно, а должно быть (со стороны View) ShowUserControls — то пробрасывайте IsAuthenticated в виде ShowUserControls.
Только не заставляйте View _знать_ что IsAuthenticated всегда равно ShowUserControls. Потому что тогда вам самому придётся это тоже запомнить, а такие мелочи копятся.
Не надо ударсять в крайности — надо искать рациональное зерно, и применять только если понимаешь зачем.
И это не преждевременная оптимизация, это Prefactoring =)
А дальше атрибутом (можно и в коде) у метода контроллера просто: @validate(schema=Registration())
В общем случае создаётся набор базовых валидаторов — для различных случаев, и они комбинируются (учитывая к примеру множетсвенное наследоание в Python). Это даёт огромный плюс в переиспользовании и унификации форм.
В практике — очень практиченое решение. Кроме того, позволяет сделать валидацию для _любой_ формы с какой угодно вложенностью и хитростями, не прибегая к сделкам с совестью.
Первоначально да. Но сущетсвенная проблема заключается в том, что рано или поздно правила валидации выходят за рамки сущностей модели, иногда противоречит им, и вы начинаете размазывать валидацию по проекту, часто дублировать её, делать исключения то там то там.
Строго говоря — вы проверяете _форму_, а не объект, поэтому валидация формы — это проверка состояния формы, а не связанных сущностей, как вырожденный случай.
Кстати, самый удачный пример реализации валидации — на мой взгляд реализовано в Python FormEncode. Где валидатор — это объект со своей гибкой структурой, произвольной вложенность, и заодно ModelBinder (в понятиях MVC).
Не делайте View слишком умными. Избегайте глобальных контекстов.
Я не настолько ортодоксален, как предлагают некоторые, чтобы избегать в них @if.
Но с точки зрения View, там где вы используете IsAuthtenticated, скорее всего должно быть свойства вроде [bool]Model.ShowUserControls и другие — смотрите на это со стороны View.
Однажды, вы захотите использовать этот же шаблон к примеру генерирующий ту же страницу в режиме для администратора: View this page from USER1 perspective. И вуаля — все ваши шаблоны это поддерживают. Это только 1 конкретный пример почему данные должны быть явными, а шаблоны глупыми.
Именно контроллер должен позаботиться о том, чтобы View была предоставленна необходимая (не больше) для него модель собранная из данных, контекста и т.п.
Унификация всех форм — это конечно утопия.
Но создание Html.InputFor(m=>m.Field), где сам label, разные звёздочки (обязательное поле) и инпут строится целиком по метаданным модели — это вполне практичный подход.
О плюсах/минусах такого подхода у себя в блоге как-то писал Jimmy Bogard. Впрочем, там много интересных заметок на тему MVC есть, среди прочего: How we do MVC
Отчасти правы, для случая с TempData[«Message»] я обычно использую обёртку из базового класса контроллера: SetTempMessage(..), а в самом базовом классе модели есть свойство TempMessage, которое используется в Layout, чтобы показать сообщение.
В контексте того, что все модели находтся в одном пространстве имён (NameSpaceProvider=False для их директорий), то имена различаются до основания. Можно убрать ViewModel и оставить Model — на вкус, суть не меняется.
Конечно для такой формы подход избыточен, но в жизни мало встречается формы из двух полей. О них и речь. Не буду же я здесь размещать килобайты разметки для повышения наглядности примера.
Но в целом всё равно выгоднее.
Интересна статистика по Windows с включёным Pagefile. Насколько сильно влияет на жизнь SSD?
Если вам в конкретном View удобно пробросить IsAuthenticated в модель — делайте это.
Если в конексте использования, вы понимаете, что IsAuthenticated не уместно, а должно быть (со стороны View) ShowUserControls — то пробрасывайте IsAuthenticated в виде ShowUserControls.
Только не заставляйте View _знать_ что IsAuthenticated всегда равно ShowUserControls. Потому что тогда вам самому придётся это тоже запомнить, а такие мелочи копятся.
Не надо ударсять в крайности — надо искать рациональное зерно, и применять только если понимаешь зачем.
И это не преждевременная оптимизация, это Prefactoring =)
Для каждой формы создаётся схема. Эти схемы могут комбинироваться, в том числе в коллекции для форм и много чего интересного.
>>> class Registration(formencode.Schema):... first_name = validators.String(not_empty=True)
... last_name = validators.String(not_empty=True)
... email = validators.Email(resolve_domain=True)
... username = formencode.All(validators.PlainText(),
... UniqueUsername())
... password = SecurePassword()
... password_confirm = validators.String()
... chained_validators = [validators.FieldsMatch(
... 'password', 'password_confirm')]
А дальше атрибутом (можно и в коде) у метода контроллера просто:
@validate(schema=Registration())В общем случае создаётся набор базовых валидаторов — для различных случаев, и они комбинируются (учитывая к примеру множетсвенное наследоание в Python). Это даёт огромный плюс в переиспользовании и унификации форм.
В практике — очень практиченое решение. Кроме того, позволяет сделать валидацию для _любой_ формы с какой угодно вложенностью и хитростями, не прибегая к сделкам с совестью.
formencode.org/Validator.html
Строго говоря — вы проверяете _форму_, а не объект, поэтому валидация формы — это проверка состояния формы, а не связанных сущностей, как вырожденный случай.
Кстати, самый удачный пример реализации валидации — на мой взгляд реализовано в Python FormEncode. Где валидатор — это объект со своей гибкой структурой, произвольной вложенность, и заодно ModelBinder (в понятиях MVC).
Я не настолько ортодоксален, как предлагают некоторые, чтобы избегать в них @if.
Но с точки зрения View, там где вы используете
IsAuthtenticated, скорее всего должно быть свойства вроде[bool]Model.ShowUserControlsи другие — смотрите на это со стороны View.Однажды, вы захотите использовать этот же шаблон к примеру генерирующий ту же страницу в режиме для администратора:
View this page from USER1 perspective. И вуаля — все ваши шаблоны это поддерживают. Это только 1 конкретный пример почему данные должны быть явными, а шаблоны глупыми.Именно контроллер должен позаботиться о том, чтобы View была предоставленна необходимая (не больше) для него модель собранная из данных, контекста и т.п.
Но создание
Html.InputFor(m=>m.Field), где сам label, разные звёздочки (обязательное поле) и инпут строится целиком по метаданным модели — это вполне практичный подход.О плюсах/минусах такого подхода у себя в блоге как-то писал Jimmy Bogard. Впрочем, там много интересных заметок на тему MVC есть, среди прочего: How we do MVC
Но опять же, это история другого романа.
Конечно для такой формы подход избыточен, но в жизни мало встречается формы из двух полей. О них и речь. Не буду же я здесь размещать килобайты разметки для повышения наглядности примера.
ADW красив, но по сравнению со стоковым Launcher2 очень требователен к ресурсам.
Постабильнее станет CM7, и если будет возможность викинуть оттуда основной тормоз — ADW Launcher — вернусь, потому как 2.3 понравился, да.