Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

asp.net MVC валидация

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Всем привет,

Меня как недавно обращенному в Веб разработку под MVC2 интересует, не является ли г0вносценарием ли следующее:

1) Есть див, который превращен посредством jquery-ui в модальную форму
2) Я хочу использовать клиентскую валидацию, чтобы юзеру сразу указать на невалидные данные, перед посылкой всех данных на сервер
3) Все данные из формы отсылаются через AJAX
4) В сценарии отправки данных всегда есть captcha. Перед отправкой всех данных на сервер сначала через AJAX валидируется капча, если она неверная — пользователю в соотв. месте об этом говорится
4) Есть http модуль, который в BeginRequest событии смотрит, а отправляется ли значение капчи. Если да, и оно не совпадает, и это — не запрос на валидацию — то запрос заворачивается нафиг (типа, читерство)
5) Меня не устраивает то, что если делать клиентскую валидацию стандартным способом (подключить скрипты че-то типа MicrosoftAjax, MicrosoftAjaxValidation или как их там, и указать HTML.ClientValidation или как его там, и генерить HTML.ValidateFor или как его там) — на каждое поле, которое не пройдет валидацию, исходя из атрибутов ComponentModel или ComponentModel.DataAnnotation членов модели, высветится валидационное сообщение. Я хочу, чтобы было на форме только одно поле, где указывалось только самое первое валидационное сообщение, которое вернется из соего метода, который будет реализовывать мой интерфейс, который будет имплементен во viewmodel, с которым работает представление.

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

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Странно, мелкомягкие могли бы сделать дотнетерам что-то чтобы не было БОЛИ от того что их же детище хреново работает, например свой клон GWT.

Кто сказал что хреново работает??? o_O Все работает как часы!!! Боль только у иноверцев от того, что еще нету php.net! :)

Я имел ввиду что БОЛЬ только на фронтенде. Из за IE.

Два запроса вместо одного. Вначале капча, потом данные с формы. Где выгода? Не видел таких сценариев. Обычно у всех всё скопом. Не понятно как это от DDoS поможет. А если капча ломается то усилит атаку ровно в два раза. Не?

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

У Сандерсона вроде же и в 2 и в 3 описана валидация модели руками. Там же и общее поле хелпер HTML.ValidationSummary для ругательств. Только не первое, а всё равно все ругательства. Но в одном месте.

То есть видел, но мне это показалось странным. Зачем давать поля если их фактически можно заполнять только после проверки капчи. Юзер их заполнит одновременно и ответит капче, отправит, ему прийдёт ответ что капча неверная, он поправит капчу и отправит опять, и тут ему скажут что и телефон не в том формате, он плюнет и уйдёт. Это на рутрекере так — ну очень захаривает, когда по три раза отправляешь одну и ту же форму и уже не понимаешь когда какое поле неправильное а когда капча. Тем более капча, она, что не будет менятся после своего аякса? А когда она будет менятся?

если их фактически можно заполнять только после проверки капчи
Нахуа.
Все заполняйте, только при валидации процесс валидации ругнется, если хоть одно валидационное правило не будет истинно. И соответственно, есть приоритеты, что валидировать в первую очередь (капча — первоочередная). Нафиг на странице куча контейнеров, каждое под свое валидационное сообщение? Оно реально напрягает.
Та нет же. Один контейнер.

HTML.ValidationSummary

www.williamspublishing.com/...459-1609-9.html

Всё таки рекамендую. Для второго тоже может быть полезно. Разница в некоторых местах между 2 и 3 существенная, во всяком случае в тех главах что я прочитал.

Я написал почему мне не нравится последовательная валидация. В реальном сценарии на рутрекере можно заполнить форму раз десять при восстановлении пароля. Очень напрягает

В смысле для MVC 2 у него тоже есть такая же книжка.

В реальном сценарии на рутрекере можно заполнить форму раз десять при восстановлении пароля.

Не читал, но осуждаю :)
Там я понял, postback без сохранения значений во viewstate ?
Если да — то это из другой оперы.

Оно сейчас работает прекрасно так: на форме в onsubmit есть обработчик, который сначала валидирует капчу (ну нафиг лишние данные слать?), если неуспешно (пришел соотв. json Ответ с ругательством) — ругнулись в контейнер. Если успешно — запостили через ajax все значения куда надо (почему все через ajax? а потому что свое webapi) и послушали ответ. Если пришел json ответ с ругательством — показали ругательство. Если ответ пришел без ругательства — делаем то, что должны делать при успешно отправке. В любом случае обработчик на onsubmit вернул false, чтоб форма не запостилась. И все прекрасно и хорошо. Ну нельзя все по книжкам делать — там вам такого понасоветуют! :)

Та нет же. Один контейнер.

HTML.ValidationSummary

это просто — текст ругательств. который если мне не изменяем память (экспериментировать влом) сразу пишется в поток ответа

postback без сохранения значений во viewstate ?

Мы же ещё про MVC говорим?

Так я без понятия, что там на рутрекере, говорю ведь — не читал, но осуждаю :) Косяк полюбому

Там проверют капчу последовательно с данными формы.

Там проверют капчу последовательно с данными формы

Ну блин, ну допустим, у вас на форме upload control с огромным файлом, и капча. Вы файл будете все время на сервер гонять?
Не знаю что там у вас за сайты, на тех сайтах, что я был — вначале отдельно проверяется капча, а потом уже отправляются данные формы.
То, что пишут в книжках — это больше теория. Чтобы не отпугнуть разработчика :)

Да и даже без mvc и всяких шняг — ИМХО желательно просто на onsubmit вешать асинхронную проверку капчи, которая просто вернет true, если капча введена правильно. Соответственно, если обработчик вернет false — данные на сервер отправлены не будут.

Э! А зачем неавторизованному клиенту отправлять файлы? Всё таки когда капча это или регистрация или вход. Какие там файлы? Фото кота? Так его на второй странице и отправлйте, уже после авторизации. Тем более если юзать асинхронную отправку то с файлом можно и подождать.

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

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

Капча — это как раз проверка, что с сервером взаимодействует не бот, а живой человек, в этом ее смысл. На авторизации она практически не нужна, т.к. авторизация делается только один раз. А вот дальнейшое взаимодействие с сервером — да, подтверждение того, что работает живой человек, а не вредоносное ПО — это обязательно. Тем более, что если сайт — не под интранет, а под всеобщую клоаку интернет

Что это за сервер такой который бесконечно от левого пользователя файлы собирает? Мегадропбокс?

Один мегабайт закончился и «давай, до свиданья!»

То есть, вы считаете, что капча не нужна при взаимодействии с сервером? Хорошо, допустим, такой сценарий: у вас сайт для публикации объявлений. На котором капча появляется только один раз — при авторизации пользователя. А не при валидации пользователя на бота :) Значит, делаем следующее:
1) Включаем Фиддлер
2) Заходим на сайт, авторизуемся, попадаем на форму отправки объявления, пишем «Привет от бота» и сабмитим.
3) Выключаем фиддлер
4) Смотрим raw request / responce
5) Находим наш request на сервер
6) Открываем студию, пишем простое консольное приложение, используем HttpRequest, получаем после соединения ссылку на поток, и в этот поток пишем бесконечно долго вот тот сырой Request. И обычно сработает, если уникальность формы никак не предусмотрена и на сервере никак не проверяется

7) На выходе, у вас в базе появится 100500 записей «Привет от бота» :)

upd: хотя, вы мне сейчас подали идею скрытой капчи и уникальной формы: представим себе некую переменную session[’variable’], в которой хранится уникальное значение, которое присутствует на форме в поле <hidden>, и данная переменная изменяется / изменяется значение этого поля при каждом посте / ajax запросе. То есть, в разрезе каждого поста, оно — уникальное. А вы ведь на клиенте ну никак не достучитесь к серверным переменным — это как в качестве пароля купюра, разорванная надвое

При сабмите / ajax запросе, это поле и передается на сервер

Тогда и капчи не надо, и от снифера, чтоб забить сервер, толку не будет — каждая форма будет уникальной

upd2: а фиг, не получится: бот считывает ответ с сервера, и парсит поле hidden :( не, нифига — не выйдет. только капча

Ну и что? Я же говорю — закончился его мегабайт или например его ограничение на количество объявлений в один день или другие бизнес-логики и «давай, досвиданья»

Если я ему позволяю отправить 1000 обяъвлений в день, то при чём тут бот или нет. Это же не WoW. А на всех досках вым больше одного-двух объявлений дать не дадут хоть с ботом хоть без. А на серъёзных досках его ещё человек проверит.

В рамках своей сессии клиент должен быть ограничен бизнес логикой, а не задрочен капчей.

То есть, отказоустойчивая работа сервера в вашем случае будет решаться всякими ограничениями в работе пользователей? а ограничения как вводить — на глаз будете? Как-то, это ИМХО гвнорешение, в частности, если, к примеру, объявления — платные, а вы — одмин :)

Один мегабайт закончился и «давай, до свиданья!»

никакого досвидания! просто, если у вас облачное хранилище данных — то оно резиновое, и за объем памяти вы платите :) а потом еще от гавна платно вычищать будете, так I/O операции в облаке платные тоже :)

Почему то дропбокс не считает это говнорешением. И вообще никто не считает. Ни хостеры ни доски обяъвлений. Более того доски ещё и на экстремизм проверяют. Привет от бота это одно, а призывы к насилию на главной это другое.

Почему то дропбокс не считает это гвнорешением

Так дропбокс деньги берет за объем, не?
www.dropbox.com/pricing

Неудачный пример

да на любой доске после десяти (одного!) объявления с одного аккаунта скажут досвиданья. и ьез всякой капчи после регистрации.

тут вы заблуждаетесь, на мой взгляд. это пространство модели, бизнес-логики, а не интерфейса.

да на любой доске после десяти (одного!) объявления с одного аккаунта скажут досвиданья

потому что это искусственное ограничение, не больше: хотите продолжать — отправьте платную СМС :) Обычно такой use-case

это пространство модели, бизнес-логики, а не интерфейса.

Вы сейчас о какой именно модели неправильно говорите? :)

Да абстрагируйтесь от досок и от дропбокса! Мы ведь с вами обсуждаем взаимодействие сферического пользователя в вакууме со сферическим сервером в вакууме, со сферической моделью поведения сервиса в вакууме :)

Да, сферически, вы пытаетесь GUI заставить подрабатывать BLL, насколько я понял.

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

Ну так если писать ботов и платить дропбоксу за миллиард фйлов «привет от бота» — это вам не кажется странным?

В том то и дело — если бы дропбокс был абсолютно бесплатным, и ресурсов немеряно, то не сделать проверку на бота — это был бы непростительный косяк.

Такого не бывает. Нигде. Даже в облаках. Разговор пошёл по замкнтому кругу.

Резюмирую — я предполагаю, что вам надо активнее использовать ограничение в виде слоя BLL.

Задача по интернализации атрибутов решена давно. В том числе и для валидации. Но я пока там не копал.

Такого не бывает. Нигде. Даже в облаках

Чего именно не бывает? Немерянно ресурсов в облаках, где вас ни в чем не ограничивают? Посмотрите amazon elastic cloud, aws storage gateway

вам надо активнее использовать ограничение в виде слоя BLL

Ни в коем случае :)

Задача по интернализации атрибутов решена давно

Наследованием? Нафиг нафиг :)

это просто — текст ругательств. который если мне не изменяем память (экспериментировать влом) сразу пишется в поток ответа

Да, но он завязан на ModelState. При желании его можно разобрать на кусочки и раскидать их в нужных местах.

Ну так дайте мне сцылко на книгу — почитаю. Хотя мне кажется, вариант с валидационным интерфейсом вместо атрибутов — в 100500 раз лучше. В том числе, вы локализацию сообщения сможете сделать (а с атрибутами ИМХО — только унаследоваться, и делать локализацию в каждом наследнике, а их-то с десяток)

ссылка битая. ну да ладно — я думал, вы сразу ссылку на pdf дадите :)

www.williamspublishing.com/...459-1609-9.html

битую я из ветки выше скопировал. привет разработчикам ДОУ

rutracker.org/...c.php?t=2967552

3-го в пдф только на английском пока

Ну нельзя все по книжкам делать — там вам такого понасоветуют! :)

Пока мой опыт подсказывает, что в книжках зачастую содержится
а) то что принято спрашивать на стековерфло, причём в первых главах

б) то что является золотой, работающей, надёжной и правильной серединой.

То есть если ты слишком далеко ушёл от книжного представления, то скорее всего скоро будешь всё упрощать и переделывать.

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

То есть если ты слишком далеко ушёл от книжного представления, то скорее всего скоро будешь всё упрощать и переделывать

Да, а asp.net mvc фреймворк появился из-за того, что его разработчик плохо знал asp.net, поэтому написал свою шнягу

Нет, потому что ASP.Net Web forms — зло которое должно здохнуть.

Ну... Не совсем. Хотя, конечно, мыслите правильно :)

Ну это — как напишете. Кешировать ее нельзя. У меня она меняется при каждой проверке / подтверждении

Где выгода?

Выгода в том, что если вы посмотрите на работу IISа, в частности, в в его пайплайн, и посмотрите как делается form authentification — вы меня поймете. То что все шлют хором, тем самым отправляя избыточные данные и нагружая контроллер (а потом плачутся — аяяй, какое гуано этот IIS и M$ и Билли) — меня как-бы мало интересует :)

У Сандерсона вроде же и в 2 и в 3 описана валидация модели руками

Я не читал Сандерсона, и даже на знаю никого, кроме Скотта Гютюрье (или как его там :), но то, что мы с ним мыслим одинаково по вашим словам — что модель нужно валидировать руками — это значит, что я на верном пути, а вы посмотрите pipeline

На StackOverflow запости там подробней помогут.

1. В любом случае должна быть реализована серверная валидация. Иначе система будет очень уязвима.

4) Есть http модуль, который в BeginRequest событии смотрит, а отправляется ли значение капчи.

(ИМХО щиткод)

— А зачем так сложно то? Нельзя отправить модель с каптчей?

Меня не устраивает то, что если делать клиентскую валидацию

Очень сложно мыслите сударь. Я обычно юзаю это:

docs.jquery.com/...gins/Validation

В любом случае должна быть реализована серверная валидация

Ну это полюбому — есть интерфейс на viewmodel, который реализует
bool IsValid(string message);
для клиентской валидации, выдающий единичное значение если хоть одно поле не провалидируется, и
bool IsValid();
который сработает на сервере, при валидации всей модели перед ее сохранением

Контроллер, производящий валидацию, на выхлопе имеет сигнатуру JsonResult

Нельзя отправить модель с каптчей

Ну а зачем нагружать контроллер при каждом чихе? Это ведь будет своего рода эшелонированная защита от DDOS

модель-то есть только на сервере, у клиента — только передаются значения

Я обычно юзаю это

я уже просто свою капчу написал :)

На StackOverflow запости там подробней помогут.

Неужели все так сложно? :)

модель-то есть только не сервере, у клиента — только передаются значения

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

public class HomeController : Controller
{
//
// GET: /Home/

public JsonResult Validate(UserModel userModel)
{
//.. bla bla
return Json(userModel,JsonRequestBehavior.AllowGet );
}
}

public class UserModel
{
public string Name { set; get; }
public int SomeField { set; get; }
}

Сериализовать модель? Опс, спасибо, попробую

Нет, все очень просто. Я проработав 1.5 года на вебе ушел. Потому что меня просто заманало писать формы, html, css и прочей фигней заниматся. Если сервер сайд, я бы еще работал, а когда идет смесь, то пошло оно все нафиг.

а когда идет смесь, то пошло оно все нафиг

Чего так?

Я понимаю когда меня жучат за то, что какаято часть того что я написал работает не так как нужно. НО, как только мне начинают говорить, что в одном браузере (например хроме) все ОК, а вот в ИЕ7 все плохо, то я понемногу начинаю ненавидеть эту работу. Когда я занимаюсь и тестированием и версткой(причем работаю за того индуса, которому заказали сделать такую верстку).

Хоть я хотел C# и JavaScript. Через пол-года меня начало передергивать от слова «Кроссбраузерность». Теперь хочу перейти на SaaS и Cloud.

Так MVC же. Чистый хтмл. Проблем практически не должно быть ни с кросс ни с броузерностью.

SaaS и Cloud.

что то мне подсказывает, что там может так запередёргивать, что голова отвалится.

Так MVC же. Чистый хтмл. Проблем практически не должно быть ни с кросс ни с броузерностью.

Да что вы говорите, MVC и кроссбраузерность. Это как «кирпич» и «синхрофазотрон». Ну да, отличий сдесь невидно.

А чистый HTML и кроссброузерность? Да, CSS всегда CSS и тут пока ничего не попишешь надо хакать. Но хаков десяток и все их уже наизусть знают. Просто чистая разметка от MVC с отрубленым CSS всегда смотрится и работает одинаково. А вот WEB FORM не всегда.

Я хотел сказать что для веба ASP.NET MVC всё-таки создаёт меньше проблем а точнее упрощает их решение для разных броузеров.

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

А чистый HTML и кроссброузерность?

Это всего лишь зависит от радиуса кривизны рук, в т.ч. разработчиков браузеров, насколько их детище хорошо поддерживает w3c стандарт. А MVC нам всего лишь дает полный контроль над разметкой, ни больше, ни меньше

MVC, что главнее, убирает руки Forms от разметки. Если говорить об MVC vs Forms.

MVC, что главнее, убирает руки Forms от разметки

Какие руки? Какие ноги? :) У вас просто нет серверных контролов, если чисто MVC, соответственно — ничего помимо вашего желания не наплюет своего в общий поток ответа.

Не бывает ничего чистого, есть задача. Нужно сделать, а то что вы господин не Осел, докажите после того как задача будет сделана.

Поделитесь, пожалуйста, своим опытом :)

Ну а зачем нагружать контроллер при каждом чихе? Это ведь будет своего рода эшелонированная защита от DDOS
модель-то есть только на сервере, у клиента — только передаются значения

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

По поводу DDOS, то боюсь вам ничего не поможет, если кто-то решит то потока в 20-40 гигабит будет достаточно.

пусть сам на своем леере делает валидацию

Ээээ неееее... Делать ОТДЕЛЬНУЮ валидацию на клиенте, оторванную от серверной модели — это очень неверно. Вот взгляните на красоту по адресу weblogs.asp.net/...validation.aspx

Единственный там недостаток- там все хором пишутся валидационные сообщения. А так на клиенте — тупо передатчик данных на сервер, на сервере они валидируются, и результат отдается клиенту. Это ведь изящнее!

По поводу DDOS, то боюсь вам ничего не поможет

Хотите задосить любой phpbb форум? Сделайте страничку с таймерным скриптов в onload, которая грузит в отдельном фрейме форум, и раз в секунду ставит ему location.href на самого себя — на ваше опубликованное там сообшение (у меня это началось, чтобы накрутить счетчик просмотра сообщения) :) При открытии на сутки 10 браузеров с 10 вкладками, уже 2 форума было убито. Знаете почему? :)

Ээээ неееее... Делать ОТДЕЛЬНУЮ валидацию на клиенте, оторванную от серверной модели — это очень неверно.

Леерная архитектура, клиент ничего не знает о серваке, вот это прелесть, когда на фрон энде сидит человек и на бек енде сидит человек. Взаимодействие происходит по заранее описаному протоколу. Когда изменения серверсайда(моделей и прочего) не трогают клиент. В этом вся прелесть, а не в том, что там по ссылке.

Вообщем, я не претендую на последнию инстанцию, но всетаки подумайте об уровнях взаимодействия.

stackoverflow.com/...-in-mvc-pattern

The source of the validation data should be in the model while the actual checking should probably be done at both the view level (perhaps with javascript or UI hints) and at the model level. Purists will suggest that the view should not be involved but I disagree.

Я соглашусь, с этим подходом. А решать задачу то вам и шишки набивать тоже.

Да, как настроите то чудо, посмотрите код страницы. Очень много интересного обнаружите вы там.

Вот, там как раз одним движением руки брюки превращаются серверная валидация вместо постбэка заменяется ajax запросом на валидацию модели, но вот только выводятся сразу и все вместе Html.ValidationMessageFor. В все в этом решении хорошо и замечательно — но нужет только самое первое сообщение из всех Html.ValidationMessageFor. Если бы их как-нибудь разместить хотя-бы каждый в своем контейнере, в одном и том же месте, а показывать только один контейнер, если в нме будет это сообщение... Но как тут без хака сделать???

А свою номальную логику валидации формы написать на JavaScript+jquery можно? Намного лутше получится. Вообщем) Не буду больше говорить, что лутше, набьете шишек сами поймете...

Единственное чем я не пользуюсь из этого фреймвока — это валидация. Особенно пугает, когда правила валидации описываются атрибутами (Data annotations) и используются как в моделях представлений так и в слое данных, например для EF сущностей. Это отлично подходит для лабораторок в универе, но для реальных сценариев даже трудно представить. Кроме того я тоже считаю, что клиентская и серверная валидация должны быть независимыми друг от друга. Нафига посылать аякс запрос чтоб проверить валидный ли эмейл, если это можно сделать средствами js. Совсем другое дело, если нужно проверить, свободен ли username в сисетеме...

Поэтому все эти MicrosoftAjaxValidation библиотеки как по мне никуда не годные. Лично я использую для клиентской валидации какой нибудь jquery плагин, а для серверной — fluent validation библиотечку.

(Data annotations) так и в слое данных, например для EF сущностей

А как это POCO EF сущности безболезненно помечены DataAnnotations атрибутами? Я вот с этим столкнулся — сущности эти — автогенерируемые, при любом чихе в модели данных все нафиг генерится заново, и атрибуты, естественно, пропадают. Посему делал отдельную ViewModel. Получилась отдельно модель представления, помеченная этими атрибутами, которая скармливается View, отдельно — доменная модель, с сущностями которых уже идет работа на основании viewmodel. А у вас как?

Нафига посылать аякс запрос чтоб проверить валидный ли эмейл

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

Я имел ввиду EF Code First, предпочитаю работать только с ним, отключая lazy loading и proxy creating. Сущности получаются достаточно читыми, валидация, если есть необходимость, настраивается как с помощью атрибутов так и с помощью fluent интерфейса. Как по мне это единственный вариант из всех 3х версий EF когда сущность можно использовать во ViewModel примерно таким образом:
class ProductViewModel
{
public Product Product {get;set;}
}
где Product это не автогенерируемая отсоединенная сущность EF code first.

Вообще в идеале во вью моделях не стоит использовать объекты слоя данных, но уж больно сильно они экономят время. Правильнее было бы перекопировать все необходимые представлению поля каким нибудь автомаппером. Ну а атрибуты можно навесить на view model также как и на entity, так даже лучше. Просто одно дело валидировать string length, а совсем другое например наличие адреса в системе, где надо и в базу лезть и т.д. Тут уже обычными арибутами не обойтись)

во вью моделях не стоит использовать объекты слоя данных,

Я разделял, писал для каждой сущности свою вью модель. Например у меня есть User(уровень данных) для него пишу UserViewModel — для того что бы изменения уровня данных не коснулись всех тех мест где я юзаю вью модель, в одном месте поправил и гуляешь дальше.

А как это POCO EF сущности безболезненно помечены DataAnnotations атрибутами? Я вот с этим столкнулся — сущности эти — автогенерируемые, при любом чихе в модели данных все нафиг генерится заново,

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

забыть о той валидацыи которую вам втюхивают мелкомягкие, она очень хреновая

Спасибо, я ж и вижу, что она хреновая (ну не сколько хреновая, просто сколько очень общая), поэтому пишу реализацию под себя — вот примерно, как Serg M подсказал с fluent validation, только на viewmodel реализуется определенный валидационный (свой) интерфейс с методами, валидирующими модель. А там уже можно сделать кстати идея — один кастомный валидационный атрибут на класс модели, который о модели будет знать только один реализуемый интерфейс с реализуемым методом конкретной валидации + дерuать стандартный метод контроллера TryValidateModel, который же и будет вызывать реализацию интерфейса на модели через этот кастомный атрибут — надо попробовать :)

Насчет атрибутов валидации — там еще такой нюанс: разве на них можно делать локализацию? Скажем, на члена модели повесить атрибут [Required(ErrorMessage="Fill in the field")] — это ж хардкод, на другой язык динамически не перевести?

Можно! Я делал) Просто создайте свой атрибут, со своими полями. Который наследует Required. Думаю все выйдет.

Так выйдет по-любому. Но я уже писал, что атрибутов этих — с десяток. Короче, я понял, что я изобрел новый шаблон валидации модели в MVC :) Надеюсь, ее включат в 5 mvc фреймворк :)

Хотя, блин, там есть такой атрибут, по которому строится HTML атрибут maxlength ...

Підписатись на коментарі