POCO - если POCO означает чистый класс .net с единственными свойствами, где я могу написать валидацию в MVC - PullRequest
Новая
       16

POCO - если POCO означает чистый класс .net с единственными свойствами, где я могу написать валидацию в MVC

0 голосов
/ 11 января 2012

Очень плохо знаком с POCO, нашел несколько ссылок Google, но нашел много разных историй.Некоторые связаны с платформой Entity, отложенной загрузкой и т. Д. Некоторые говорят, что это чистый класс .det.Atleast MSDN.

ССЫЛКА ДЛЯ ОПРЕДЕЛЕНИЯ POCO ИЗ MSDN: msdn.microsoft.com / en-us / library / dd456872.aspx

Я доверяю MSDN (простое определение) и предположим, что это чистый класс .NET.

Теперь позвольте мне перейти к сути.ЕСЛИ это чистый класс .net, имеющий только свойства внутри него, то он эквивалентен «МОДЕЛИ» в MVC.пример. 

 [Required(ErrorMessage = "Full Name  required.")]
    [StringLength(20, ErrorMessage = "Username must be under 20 chars.")]
    public string UserName { get; set; }

    [Required(ErrorMessage = "Email required.")]
    [RegularExpression(".+@.+\\..+", ErrorMessage = "Email not valid.")]

    public string Email { get; set; }

    [Required(ErrorMessage = "PassWord required.")]
    [StringLength(20, ErrorMessage = "Maximum 20 chars. allow")]
    [DataType(DataType.Password)]
    public string Password { get; set; }

До этого уровня мне это понятно.Теперь, если я хочу написать свою собственную проверку (условную) в MODEL, используя

ValidationAttribute или

IValidatableObject

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

public class Wizard  : ValidationAttribute,IValidatableObject
{
    public override bool IsValid(object value)
    {
        return base.IsValid(value);
    }

    public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
    {
        throw new NotImplementedException();
    }
    [Required(ErrorMessage = "Full Name  required.")]
    [StringLength(20, ErrorMessage = "Username must be under 20 chars.")]
    public string UserName { get; set; }

    [Required(ErrorMessage = "Email required.")]
    [RegularExpression(".+@.+\\..+", ErrorMessage = "Email not valid.")]

    public string Email { get; set; }

    [Required(ErrorMessage = "PassWord required.")]
    [StringLength(20, ErrorMessage = "Maximum 20 chars. allow")]
    [DataType(DataType.Password)]
    public string Password { get; set; }
}

Это все еще POCO?Если да, то как он может содержать методы. (Напротив ссылки MSDN) Если НЕТ, где я должен записать свой код проверки (конечно, условная проверка в MVC).Ищете действительно хороший ответ на примере.

Ответы [ 3 ]

3 голосов
/ 11 января 2012

POCO означает, что вам не нужно наследовать от некоторого базового класса, определенного каркасом, для реализации функциональности. По сути, вы можете свободно разрабатывать иерархию классов.

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

Примером счетчика будет наследование от EntityObject класса для сущностей в Entity Framework.

2 голосов
/ 11 января 2012

В связанной статье не сказано, что в POCO не должно быть методов. Ясное описание того, что такое POCO, можно найти в Wikipedia :

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

POCO может иметь все необходимые вам методы или логику. Разница между POCO и не-POCO заключается в том, что POCO - это класс, который вы можете использовать всегда, даже если вы не используете конкретную платформу (EF), но не POCO можно использовать только тогда, когда конкретная структура связана или даже хуже инициализирована и используется.

Для аннотаций данных пуристов также нарушается POCO, потому что они также требуют определенного API, но в прагматическом подходе аннотации данных в порядке (за исключением специальных аннотаций, используемых в EF Code сначала для определения отображения), поскольку они приносят зависимость только к способу проверки сущности но не зависимость от того, как сущность сохраняется (объект не POCO EF). Зависимость от постоянства может потребовать ссылки на EF в сборках, где вы никогда не собираетесь использовать EF - например, на уровне представления, таком как приложение MVC.

1 голос
/ 11 января 2012

Лично мне нравится делать мои POCO частичными классами с базовыми свойствами, необходимыми для определения этой модели, а затем помещать и проверять логику в отдельный класс.например: 

public partial class Wizard
{
    public string UserName { get; set; }
    public string EmailAddress { get; set; }
}

, а затем, если я хочу добавить проверку к UserName: 

public partial class Wizard
{
    [Required]
    [StringLength(20)]
    public string UserName { get; set; }
}

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

Другой вариант - использовать атрибут MetadataType .

...