Как / где применять бизнес-правила к объектам POCO?

Question

Допустим, у меня есть POCO со следующим:

    [DataMember]
    public Nullable<int> MetricId
    {
        get { return _metricId; }
        set
        {
            if (_metricId != value)
            {
                _metricId = value;
                OnPropertyChanged("MetricId");
            }
        }
    }
    private Nullable<int> _metricId;

Я хочу подтвердить, что MetricId строго больше 0

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

Спасибо!

Answer 1

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

Answer 2

Это не чисто, используя частичные классы. Допустим, у вас есть абстрактные классы продукта и производные классы онлайн-продукта и магазина.Оба наследуют цену имущества, но цена разная.И скажем, бизнес-логика тоже может быть другой.Теперь у вас есть два дополнительных класса, которые вам не нужны.В большей системе это умножается.

Answer 3

После прочтения комментариев и ответов кажется, что создание другого класса - это хорошо, но, сделав его частичным, он напрямую связывает мою бизнес-логику с Entity Framework и сгенерированным кодом POCO. Это вызывает беспокойство, потому что, как EF4 меняется на EF5, а шаблон T4 меняется на шаблон T5, что произойдет с моим кодом? Кроме того, я просто не чувствую себя комфортно, используя частичные классы в качестве обычных классов.

Вместо этого, и кто-то может все же предоставить лучший ответ (пожалуйста, сделайте), я думаю, что создание независимого от фреймворка объекта (не привязанного к EF) лучше. Затем я могу сопоставить его с общим бизнес-объектом. Что-то вроде:

    static Customer Map(CustomerPOCO poco)
    {
        return new Customer
        {
            CustomerId = poco.CustomerId
            ...
            ...
        };
    }