Используя MVC и быстрый Nhibernate, как я проверяю уникальные поля на своем ViewModel, прежде чем я свяжу их со своим Объектом области и Сохраню их?

У меня нет ответа на ваш вопрос, но вы можете проверить сайт sharparchitecture.net. Он содержит несколько лучших практик для asp.net mvc и nhibernate. Также я могу порекомендовать вам проверить проект xval и руководства по проверке с помощью валидаторов аннотаций данных

Я нашел решение, которое работает для меня, - это

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

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

using System;
using NHibernate;
using NHibernate.Event;
using Validation.Entities.Interfaces;
using Persistence.SessionBuilder;

namespace Persistence.Validation
{
    public class ValidationEventListener : IPreInsertEventListener, IPreUpdateEventListener
    {

        public bool OnPreInsert(NHibernate.Event.PreInsertEvent @event)
        {
            var entityToInsert = @event.Entity as IBusinessBase;

            if (entityToInsert != null)
            {
                if (entityToInsert.BrokenRules != null)
                {
                    RollbackTransactionBecauseTheEntityHasBrokenRules();
                }
            }

            return false;
        }

        public bool OnPreUpdate(NHibernate.Event.PreUpdateEvent @event)
        {
            var entityToUpdate = @event.Entity as IBusinessBase;

            if (entityToUpdate != null)
            {
                if (entityToUpdate.BrokenRules != null)
                {
                    RollbackTransactionBecauseTheEntityHasBrokenRules();
                }
            }

            return false;
        }

        private void RollbackTransactionBecauseTheEntityHasBrokenRules()
        {
            try
            {
                ISession session = SessionBuilderFactory.GetBuilder().CurrentSession;

                if (session != null)
                {
                    session.Transaction.Rollback();
                }
            }
            catch (Exception ex)
            {
                //this will force a rollback if we don't have a session bound to the current context 
                throw new NotImplementedException();
            }
        }
    }
}

Если вы определяете уникальное ограничение в базе данных, то почему бы не делегировать ответственность за проверку того, существует ли уже уникальное значение в базе данных? Используя NHibernate, вы можете использовать интерфейс NHibernate.Exceptions.ISQLExceptionConverter для захвата и преобразования известных ошибок, связанных с нарушениями ограничений. Вы также можете использовать средства реализации NHibernate.Exceptions.IViolatedConstraintNameExtracter (см. NHibernate.Exceptions.TemplatedViolatedConstraintNameExtracter ), чтобы получить неряшливую информацию об исключении вашей базы данных и преобразовать его в удобное для пользователя сообщение. , переупакуйте как исключение проверки по вашему выбору и перехватите его в соответствующем контроллере.

Пример быстрого, очень конкретного быстрого и грязного конвертера исключений из одного из моих проектов:

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

Когда дело доходит до проверки модели, когда вы находитесь в процессе привязки Да, вы можете легко использовать службу, репозиторий или что-то еще в вашей архитектуре в методе ValidateSelf. Я думаю, что возникает вопрос: а как же эта зависимость?

Если я правильно помню, вы можете создать свой собственный связыватель, который будет использовать вашу инфраструктуру внедрения зависимостей для подключения любых сервисов, необходимых вашей модели для проверки при ее создании, вызвать связыватель по умолчанию MVC для заполнения объекта, затем вызвать Структура Castle Validation для проверки. Это н'

Обычно я помещаю уровень сервиса между моими контроллерами и репозиториями.
Затем уровень сервиса будет обрабатывать валидацию и вызовы репозитория.

Затем, если есть ошибка валидации на уровне сервиса, я генерирую настраиваемое исключение, перехватываю его в контроллере и вставляю ошибки в состояние модели. .