Утверждение части модели в MVC

Question

Я пытаюсь обернуть голову, делая проверку в сценарии MVC. Я настроил приложение так, чтобы оно имело слой данных / репозитория, который использует Linq2SQL и создает объекты в моей доменной модели. Я не предоставляю свои объекты Linq2SQL напрямую остальной части моего приложения, однако, сейчас моя модель предметной области в основном похожа на мои таблицы базы данных. Я хотел сделать это на тот случай, если позже захочу удалить Linq2SQL.

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

Я хочу использовать среду проверки, такую ​​как xVal . Похоже, что ваша модель должна содержать ваши правила валидации. Мой вопрос: как вы проверяете часть модели (или различные состояния)? Например, у меня есть объект User, который имеет имя пользователя, пароль и другие свойства. У меня есть действие входа в систему, в котором я хотел бы убедиться, что указаны имя пользователя и пароль. Однако, когда я создаю нового пользователя, я бы хотел, чтобы требовалось больше полей. Кажется странным создавать объект Login в моей модели, когда у меня уже есть объект User.

Прямо сейчас мое действие по входу в систему просто принимает параметры имени пользователя и пароля, которые ему отправлены.

Answer 1

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

Подумайте вместо пользователя, который может быть анонимным или может быть заполнен. Простой способ понять, что у пользователя есть экземпляр объекта Credentials; это также хорошее место для отслеживания разрешений и т. д.

Answer 2

Извините, но я не могу думать дальше вашего примера. Пользовательский объект не должен иметь метод входа в систему. То, что я делаю, имеет следующее

public class User
{
  public bool ConfirmPassword(string password)
  {
    ... 
  }
}

Тогда хранилище. Он находит пользователя по его userName, а затем проверяет ConfirmPassword, чтобы убедиться, что он верный, если нет, возвращает ноль.

public interface IUserRepository
{
  ..other stuff..
  User GetByUserNameAndPassword(string userName, string password);
}

Что касается проверки, у меня обычно есть 2 способа получения ограничений.

//The constraint itself
public interface IConstraint
{
  string Name { get; }
  bool IsValid();
}

//A way to get constraints that are inexpensive to evaluate, such
//as Name != null etc.  This can be implemented as a service to provide
//custom constraints from an external source (such as rows in a DB)
//which then additionally checks "instance" if it implements the
//interface and adds its constraints to the result too.

//These are the kinds of constraints I evaluated in the GUI every
//time the object changes, so I can show a list of errors.
public interface IConstraintProvider
{
  IEnumerable<IConstraint> GetConstraints(object instance);
}

//Finally a way to get constraints that are expensive to evaluate, this
//includes checking invariants that might involve DB access.  These constraints
//(along with the cheap evaluation constraints) are all evaluated before
//my persistence service attempts to write the object's changes to the DB
public interface IPreSaveConstraintProvider
{
  IEnumerable<IConstraint> GetConstraints(object instance);
}