проверка взаимодействия с базой данных asp.net mvc

Есть ли у кого-нибудь ссылки или советы о том, как подключить проверку, которая требует взаимодействия с базой данных перед обновлением или добавлением в базу данных? Каждый пример, который я вижу, показывает, как проверять свойства, например. «Требуется», «Электронная почта», «Числовой» и т. Д., Но как подключить проверку на «Невозможно заказать товар, отсутствующий на складе»? Это сообщение в блоге xVal касается этого, но не приводит пример.

Я слежу за учебником NerdDinner, в котором используется репозиторий, но это то, что я не совсем понимаю ... Скажем, у нас был OrderController с методом Create, и перед созданием заказа нам нужно было сначала проверить, что элемент есть в наличии. В стиле NerdDinner Контроллер использует Репозиторий для взаимодействия с базой данных, поэтому как наш объект Order (Модель) сможет обеспечить эту проверку вместе с проверкой свойства, если он не может разговаривать с база данных?

Спасибо за любую помощь


validation asp.net-mvc
person atwrok8    schedule 16.05.2009    source источник

Ответы (3)


arrow_upward
3
arrow_downward

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

В NerdDinner GetRuleViolation позволяет извлекать нарушенные правила и переносить их в интерфейс по вашему выбору.

    public bool IsValid
    {
        get { return (GetRuleViolations().Count() == 0); }
    }

    public IEnumerable<RuleViolation> GetRuleViolations()
    {


        if (CheckDbForViolation)
            yield return new RuleViolation("Database Violation", "SomeField");

        if (String.IsNullOrEmpty(Title))
            yield return new RuleViolation("Title is required", "Title");

        if (String.IsNullOrEmpty(Description))
            yield return new RuleViolation("Description is required", "Description");

        if (String.IsNullOrEmpty(HostedBy))
            yield return new RuleViolation("HostedBy is required", "HostedBy");

 ... etc ...


        yield break;
    }

    public bool CheckDbForViolation()

    {

    /// Do your database work here...

    }

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

person Mitch Baker    schedule 16.05.2009
comment
Я читал об IsValid и GetRuleViolations, но здесь нет упоминания о сценарии «Невозможно заказать товар, отсутствующий на складе». Где можно разместить бизнес-правила этого типа? Благодарность - person atwrok8; 17.05.2009
comment
Одним из шагов проверки будет запрос к базе данных, чтобы узнать, есть ли товар на складе. Затем либо продолжайте, если у вас все в порядке, либо потерпите неудачу и предотвратите запись в базу данных. - person Mitch Baker; 17.05.2009
comment
Я понимаю, что такое этап проверки, но КУДА будет идти логика? Контроллер использует репозиторий, поэтому для запроса базы данных эта логика должна быть в контроллере, однако я понимаю, что бизнес-правила должны оставаться в модели? Я начинаю думать, что Контроллер не должен использовать Репозиторий ?! Благодарность - person atwrok8; 17.05.2009
comment
Извините, что я не стал более понятным ... Если вы войдете в файл Models / Dining.cs, вы добавите код проверки, который просматривает базу данных как вызов метода в методе GetRuleViolations. Я бы сделал это вызовом метода, чтобы метод GetRuleViolations оставался красивым, чистым и легким для интерпретации. Это проясняет? - person Mitch Baker; 17.05.2009

arrow_upward
1
arrow_downward

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

Я с самого начала решил не использовать ни встроенную проверку, ни API членства, чтобы в какой-то момент не столкнуться с его ограничениями.

Для вашей ситуации: это довольно стандартно.

Представьте себе поток выполнения следующим образом:

  1. Форма сообщения
  2. Проверить формат входных данных, не обращаясь к базе данных
  3. Если (2) пройден, вы подтверждаете ввод с точки зрения бизнес-правил / целостности данных. Здесь вы разговариваете с базой данных
  4. Если (3) пройден, выполните свою операцию, как бы она ни была. Если это каким-то образом не удается (возможно, правила целостности данных в базе данных запрещают операцию, скажем, вы удалили связанный объект из другого окна браузера), то отмените ее и уведомите пользователя об ошибке операции.

Старайтесь, чтобы методы контроллера оставались как можно более пустыми. Логика проверки и работы должна находиться в ваших моделях и бизнес-логике. Контроллер должен в основном попытаться выполнить одну намеченную операцию и на основе возвращенного статуса просто вернуть то или иное представление. Может быть, еще несколько вариантов, но не вся масса проверок ролей пользователей, прав доступа, вызова некоторых веб-сервисов и т. Д. Будьте проще.

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

person User    schedule 16.05.2009
comment
Указанный вами поток выполнения - это именно то, что я сделал бы, я просто не уверен в терминах примера NerdDinner, где будет размещаться проверка. Для меня было бы больше смысла, если бы объект Order использовал Репозиторий, а затем Контроллер говорил исключительно с объектом Order. Таким образом, объект Order будет обрабатывать обе формы проверки, поскольку теперь он может взаимодействовать с базой данных. Как вы думаете, это будет лучший вариант? Благодарность - person atwrok8; 17.05.2009
comment
Я не так хорошо знаком с примером NerdDinner. Если репозиторий представляет собой какой-то уровень базы данных, в то время как существует промежуточный уровень бизнес-логики (ваш Заказ, например, может считаться бизнес-объектом), для контроллера явно неправильно использовать репозиторий напрямую для каких-либо целей. Связь должна быть: [Контроллер] ‹-› BLL ‹-› DAL. Иногда вы просто используете модели вместо BLL, но это не совсем правильно. Модели нужны только для того, чтобы упаковать данные для отображения. - person User; 17.05.2009

arrow_upward
0
arrow_downward

Я бы создал OrderService с помощью метода PlaceOrder (Order order). OrderService использует репозиторий для выполнения операций CRUD и обеспечения соблюдения бизнес-правил (проверка запасов) и, в конечном итоге, вызывает исключение при нарушении правил, которое вы можете поймать и сообщить пользователю.

person Andrea Balducci    schedule 16.05.2009
comment
Я надеялся сохранить это в контексте NerdDinner и в данный момент не пользоваться услугами. Хотелось бы, чтобы все было как можно проще, чтобы понять, как все это устроено. Благодарность - person atwrok8; 17.05.2009