Я читал про инфраструктуру asp.net mvc 2.0, и я немного запутался, что мне следует использовать для проверки, куда она должна пойти и как убедиться, что мне не нужно писать один и тот же код.
Мои сайты, как правило, почти полностью совместимы с jquery. Так что я обычно делал jquery.validate для моей клиентской стороны, а затем на стороне сервера снова проверял. Если произойдет сбой на стороне сервера или если у меня будет правило проверки, я не смогу протестировать на стороне клиента, я верну сообщения об ошибках.
Пара вещей - это отстой. Сначала я должен убедиться, что сообщения об ошибках одинаковы на стороне клиента и на стороне сервера. Поэтому у меня всегда будет 2 повторяющихся сообщения.
Так что, если я неправильно произношу слово, я должен убедиться, что не забываю поменять его в 2 местах. Во-вторых, трудно возвращать ошибки на стороне сервера (большинство моих сайтов - почти все ajax), поэтому я всегда проверял наличие флага.
$.post('Create',{'test',test},function(response)
{
if(response.IsValid == false)
{
// check other json parameters to get all error msgs
// add them to some div container and display to user.
}
else
{
// show success msg.
}
}):
Я просматривал аннотации данных, но я не уверен, помогут ли они мне, так как я использую сообщения ajax.
Будет ли код на стороне клиента отображаться, если вы нажмете кнопку, подключенную к сообщению ajax?
Я также предполагаю, что сообщения на стороне сервера никогда не будут отображаться, так как это не зависит от поиска помощников по проверке HTML, которые нуждаются в полном отображении страницы?
Я также считаю их довольно ограничивающими. Я знаю, что вы можете написать свой собственный, но, похоже, это очень много для написания (на стороне сервера и на стороне клиента), тем более что мне пришлось бы писать в основном все предложения jquery validate.
Существует ли библиотека, обновляющая активность, которая позволяет вам использовать аннотации данных с jquery.validate (включая удаленный, который jquery.validate)?
Наконец, я не знаю, куда этот код должен идти. Автор книги как-то меня смутил.
у него
public class Appointment
{
[Required(ErrorMessage = "Please enter your name")] [StringLength(50)]
public string ClientName { get; set; }
[DataType(DataType.Date)] [Required(ErrorMessage = "Please choose a date")]
public DateTime AppointmentDate { get; set; }
}
У него есть базовое подтверждение в том, что, кажется, модель Вей. Я понимаю это, но что меня смутило, так это то, что в классе обслуживания он снова проводит базовую проверку и проверку бизнеса.
namespace BookingsExample.Domain.Services
{
public class AppointmentService
{
public static void CreateAppointment(Appointment appt)
{
EnsureValidForCreation(appt);
// To do: Now save the appointment to a database or wherever
}
private static void EnsureValidForCreation(Appointment appt)
{
var errors = new RulesException<Appointment>();
if (string.IsNullOrEmpty(appt.ClientName))
errors.ErrorFor(x => x.ClientName, "Please specify a name");
if (appt.AppointmentDate < DateTime.Now.Date)
errors.ErrorFor(x => x.AppointmentDate, "Can't book in the past");
else if ((appt.AppointmentDate - DateTime.Now.Date).TotalDays > 7)
errors.ErrorFor(x => x.AppointmentDate, "Can't book more than a week in advance");
if (appt.ClientName == "Steve" && appt.AppointmentDate.DayOfWeek == DayOfWeek.Saturday)
errors.ErrorForModel("Steve can't book on weekends");
if (errors.Errors.Any())
throw errors;
}
}
}
Только потому, что ваш уровень модели обеспечивает
свои собственные правила не означает, что вы должны
прекратить использование встроенного в ASP.NET MVC
поддержка валидации. Я считаю это полезным
думать о проверке ASP.NET MVC
механизм в качестве полезной первой линии
защита, которая особенно хороша в
генерирование проверки на стороне клиента
Сценарий практически без работы. Он подходит
в аккуратном виде с узором модели
(т. е. имея простой вид
модели, которые существуют только для передачи
данные между контроллерами и представлениями и
не держи бизнес логику): каждый взгляд
Класс модели может использовать аннотации данных
атрибуты для настройки на стороне клиента
проверка.
Но, тем не менее, ваш домен не должен
доверять своему уровню пользовательского интерфейса для обеспечения соблюдения
бизнес правила. Настоящее исполнение
код должен войти в домен с помощью
какая-то техника, такая как у вас
только что видел. *
- Это из книги по инфраструктуре pro asp.net mvc 2.0, глава 12.
Я могу понять, почему он это делает, чтобы он мог использовать уровень обслуживания и использовать его в разных проектах (т. Е. У вас есть какое-то мобильное приложение на вашем сайте, и вам нужно использовать ту же бизнес-логику).
Тем не менее, выглядит несколько излишним, что он пишет одни и те же сообщения в 2 местах, и теперь он должен обновить сообщение в 2 местах. Я также не уверен, почему он не доверяет «пользовательскому интерфейсу» выполнять проверку, потому что он проверяется на стороне сервера, и это должно быть безопасно.
Так не будет ли лучше иметь все это на уровне обслуживания? Или лучше оставить простые обязательные поля в моделях представления для проверки?