Элегантные методы проверки для сайта Entity First MVC3?

Question

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

Мы определенно собираемся использовать метод "Entity First" и у нас будет один файл .edmx, определяющий модели, тамЕсть много причин для этого, но просто знайте, что это определенная часть головоломки.

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

Существуют ли уже популярные методы для выполнения некоторых базовых проверок?Такие вещи, как MaxLength или Required или MinDate и т. Д.?

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

РЕДАКТИРОВАТЬ
Я должен указать на пару важных фактов.
1) Наша база данных уже существует и была создана администратором базы данных еще до того, как разработчики вошли в картину.
2) Уже созданы сотни таблиц и хранимых процедур.
3) Когда необходимо будет внести изменения в базу данных, они пройдут через администратора баз данных, к которому у нас не всегда будет мгновенный доступ.

Answer 1

Мариус пытается сказать вам, что «Code First» относится к вашей «модели», определяемой текущими отображениями кода, которые не зависят от файла .edmx.Поэтому, если вы используете файл .edmx, вы не делаете «сначала код».Вы используете либо «Сначала база данных», либо «Сначала модель» (оба из которых используют .edmx).

В вашем случае у вас уже есть база данных, поэтому вы используете «Сначала база данных»подход, используя EF 4.1 DbContext.Это не «Code First» (или, как вы неправильно указали, Entity First).Это не семантическая придирка, так как «сначала код» имеет очень специфическое значение.Это не так.

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

EF предназначен для представления вашей реляционной модели данных в объектах и ​​генерирует все свои собственные sql для доступа и заполнения этих объектов.Если вам придется пройти через звезд, EF будет для вас постоянной тяжелой битвой.

Answer 2

Я бы на 100% все равно использовал какой-нибудь класс POCO. Загрузите шаблон генератора DBContext, который сначала создаст код из вашей модели, ИЛИ воспользуйтесь мощными инструментами Entity Framework для обратного проектирования существующей базы данных. Недостатком этих методов является то, что вы не получите проверку на стороне клиента, только при сохранении вы получите проверку. Однако вы все равно можете добавить свои атрибуты проверки, если выберете проверку на стороне клиента, дополнительно используя Классы метаданных для использования аннотаций данных в ваших свойствах и получения проверки на стороне клиента с использованием встроенной ненавязчивой проверки jQuery.

Однако - то, о чем мы здесь говорим, в любом случае идет вразрез с базовым дизайном хороших практик MVC. В идеале ваши представления должны иметь ViewModel, которые иногда являются только частью сущности, в этом случае ваши атрибуты проверки все еще генерируются в ваших свойствах как DataAnnotations в MetaDataClasses.

Если вы чувствуете, что это слишком много работы, и вы в порядке только с проверкой сервера и приняли решение не использовать ViewModels и полагаться на проверку Entity Frameworks или использовать ViewModels и по-прежнему полагаться на проверку EF, тогда вы для перехвата следующего исключения понадобится обработчик, подобный следующему, в вашем контроллере (или другом слое, которому был предоставлен доступ к ModelState). Примечание. Я использую AutoMapper для копирования свойств из моей ViewModel в мою сущность.

Entity Framework Power Tools (щелкните правой кнопкой мыши в своем проекте в обозревателе решений после его установки, и появится новое меню «Entity Framework» -> Reverse Engineer - обратите внимание, что он не генерирует атрибуты [TimeStamp] и забывает вводить имена схем - кроме того, это довольно хорошо)

[HttpPost]
public ActionResult Create(CustomerCreateViewModel customerViewModel)
{
    if (ModelState.IsValid)
    {
        try
        {
            Mapper.CreateMap();
            Customer customer = Mapper.Map(customerViewModel);

            var repository = new CustomerRepository(db);
            repository.Save(customer);
            return RedirectToAction("Edit", new { id=customer.CustomerId});
        }
        catch (DbEntityValidationException ex)
        {
            foreach (var error in ex.EntityValidationErrors.First().ValidationErrors)
            {
                this.ModelState.AddModelError(error.PropertyName, error.ErrorMessage);
            }
            return View();
        }
    }
    return View(customerViewModel);
}

Answer 3

У Джона Галлоуэя есть хорошая статья под названием Генерация EF-кода. Первые классы модели из существующей базы данных , которые, я думаю, очень помогут вам в работе над приложением и переходе от того, что вы описали.

* 1004Во-вторых, благодаря созданию нашего собственного MVC-приложения я обнаружил, что вы действительно не собираетесь работать с моделями Entity Framework напрямую очень часто.Большую часть времени вы будете иметь какую-то модель представления для получения и получения сообщений.Добавление DataAnnotations к этим свойствам класса позволит вам очень легко выполнять проверки на стороне клиента.После того, как вы проверили данные со стороны клиента и проверили свои сущности на соответствие любым бизнес-правилам, вы действительно сможете доверять данным и использовать EF для выполнения своей основной работы с CRUD.

Удачи инадеюсь, это поможет вам в вашем проекте.

Answer 4

Прежде всего, если вы используете Entity Framework Code First, у вас нет файла .edxm, в котором хранятся ваши модели или отношения между ними: вы просто пишете свои классы POCO (Plain Old CLR Object), и на этом все - CodeСначала выясним отношения между вашими моделями на основе соглашений об именах.

---

Для проверки ваших (просмотра) моделей, я рекомендую использовать FluentValidation или DataAnnotations .Оба позволяют вам определять правила проверки в одном месте, используя либо свободный API проверки в различных классах проверки сущности (FluentValidation), либо используя атрибуты для украшения свойств вашей сущности (DataAnnotations).Преимущество DataAnnotations перед FluentValidation заключается в том, что вы получаете дополнительную проверку на стороне клиента из коробки.

Какой бы фреймворк вы ни выбрали, оба поставляются с кучей предопределенных правил проверки, таких как Обязательный , Диапазон , или Макс. Длина (см. Свободное подтверждение для .NET или System.ComponentModel.DataAnnotations Пространство имен для примеров).