EF4 сначала код, а сначала модель в отношении проверки модели

Question

Я работаю над проектом ASP.NET MVC 3, состоящим из одного человека (у меня есть полный контроль над схемой и кодом базы данных), и я пытаюсь сделать выбор между использованием базы данных сначала и POCO с моими моделями EF4,или если я должен идти с / code-first.

Главное, чего я пытаюсь добиться, - это украсить мои модели с помощью атрибутов DataAnnotation, чтобы я мог обеспечить проверку схемы до выполнения какого-либо сохранения.Глядя на статью Скотта Гатри о проверке модели с MVC 2, он рассказывает о статье о том, как сделать это с помощью кода сначала (шаг 2), и с помощью модели сначала (или базы данных), используя "приятельские классы "(Шаг 5).

Я исторически проектировал свою базу данных с использованием графического интерфейса разработчика SQL Server (и сценариев), поэтому я определенно более продуктивен в этом, особенно когда речь идет о разработке базы данных.Однако, если я не откажусь от идеи декорирования своих моделей с атрибутами DataAnnotation для проверки, я буду нарушать DRY, не только имея свойства модели в двух классах, но и, по сути, создавая мою схему в двух местах.

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

Answer 1

First Code First находится в CTP и поэтому не имеет действующей лицензии.Если это проект, который будет реализован в ближайшие пару месяцев, то сначала принимается решение о модели.

Сказав это, классы Code First, использующие DataAnnotations, являются более чистыми, чем POCO Model First с классами собеседников, но самым важным в моем опыте является явное намерение.Пока ваш дизайн ясен и, что наиболее важно, согласован, любой из подходящих подходов подходит.

Для небольшого проекта (например, одного человека, как вы заявили), я бы сказал, что вы, вероятно, будете более продуктивны с ModelСначала и проектирование через EDMX.Это также будет более удобным для вас, если вы исходите из схемы первого фона.Однако есть несколько обручей, через которые вам нужно пройти, чтобы классы POCO работали хорошо, например, установить шаблон POCO T4, а затем изменить шаблон T4, созданный в вашем проекте, чтобы вытащить POCO в отдельную сборку.Вы не хотите их в сборке DAL, где они начнут.Затем вам остается решить, насколько вам комфортно с частичными классами для реализации DataAnnotations;по причинам, с которыми я не согласен, многие люди считают это плохим дизайном.

В проекте MVC вы столкнетесь с вездесущей проблемой СУХОЙ, используя DataAnnotations с любым подходом, когда решите использовать ViewModels.В этот момент вы внезапно поймете, что обширная аннотация вашей Модели для проверки полезна, только если вы счастливы отправлять эти классы прямо в представление.Если вы решите сохранить представления легкими и использовать ViewModels, вам придется повторить DataAnnotations в ViewModel, в противном случае у вас останутся ошибки проверки на уровне модели, но нет способа получить это в ModelState, кроме добавления вручную.Ни код, ни модель сначала не решают эту проблему, поэтому вам необходимо разработать соответствующий проект.Мы лично сделали микс и приняли уровень DRY.

Answer 2

Какой тип проверки вы ищете? Вы хотите внедрить правила проверки пользовательского ввода в сущности или вам нужен слой проверки только поверх операций с базой данных?

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

Код EF сначала вводит аннотации данных, используемые для проверки уровня БД (кстати, проверка уровня данных может полностью отличаться от проверки пользовательского интерфейса). Я попробовал точно такой же подход с файлом EDMX, прежде чем эта функция была впервые представлена ​​в Коде. Вы можете определить атрибуты проверки для классов, сгенерированных шаблоном EF T4 POCO. Проблема с моей реализацией проверки (основанной на рефлексии) заключалась в том, что если я выполнял много обновлений и вставок, это было очень медленно - я еще не сравнивал его с кодом.

Edit:

На основании текущего объявления в блоге команды ADO.NET следующий выпуск EF (RC планируется до конца марта) будет поддерживать проверку во всех трех подходах: сначала код, сначала база данных, сначала модель. Я до сих пор не уверен, что это означает поддержку проверки в реализациях на основе DbContext и ObjectContext.

Answer 3

Вы действительно не проверяете DRY здесь. Концепция DRY немного более тонкая, чем простое дублирование кода. Существуют приемлемые компромиссы, особенно с учетом проблем сопряжения.

Когда люди задают этот вопрос, что довольно часто, если вы ищите, я обычно отсылаю их к концепции [ограниченных понятий] DDD [1]. Использование [Remote] и принудительное использование DRY, когда дело доходит до проверки, приводит к объединению множества проблем в одном месте и объединению обязанностей нескольких уровней. Бизнес-логика против постоянства и логики целостности данных (ненулевые).

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

Скопировано здесь: Пользовательская проверка MVC 3 и DRY