Методы проверки в сущности - PullRequest
0 голосов
/ 30 марта 2012

Я использую Domain-Driven-Design, у меня есть объект под названием Menu, необходимо проверить, имеет ли элемент до трех уровней, теперь класс такой, как показано ниже:

 public class Menu : Entity
    {

        public virtual AreaMenu AreaMenu { get; set; }

        public virtual Menu MenuPai { get; set; }

        public string Title{ get; set; }

        public virtual Site Site { get; set; }

        public Status Status { get; set; }

        public byte StatusId
        {
            get { return (byte)Status; }
            set { Status = (Status)value; }
        }

        public bool VerifyLevels()
        {
            if (this.MenuPai == null || this.MenuPai.MenuPai == null || this.MenuPai.MenuPai.MenuPai == null || this.MenuPai.MenuPai.MenuPai.MenuPai == null)
                return true;

            return false;
        }
    }

Это проверка уровней (public bool VerifyLevels()), правильно ли быть здесь в сущности или правильно, что она находится в хранилище?

Ответы [ 2 ]

1 голос
/ 30 марта 2012

Да, правильно ставить валидации в вашей сущности. С другой стороны, вы можете вызвать эту проверку из вашего метода репозитория Save для проверки перед сохранением

* 1003 Е.Г. *

public class MenuRepository : IMenuRepository
{
    public bool Save(Menu menu)
    {
        if (!menu.VerifyLevels())
            return false;

        if (menu.ID == 0)
            context.Menus.AddObject(menu);
        else
            context.ObjectStateManager.ChangeObjectState(menu, EntityState.Modified);
        context.SaveChanges();

        returns true;
    }
}
1 голос
/ 30 марта 2012

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

Некоторым людям нравится сохранять слой своей модели сущности очень легким и чистым - и, следовательно, не помещать туда никакой проверки.* По моему личному мнению, сущности не являются DTO (объектами передачи данных) и поэтому не должны быть анемичными.Мне не нравятся анемичные доменные модели, потому что это отвлекает от повторного использования кода: http://en.wikipedia.org/wiki/Anemic_domain_model

...