ComponentModel.DataAnnotation 和装饰器模式有什么区别？

Question

我正在我的项目中实现存储库装饰器模式：

[Auditable]
public class Product
{
    public int Id {get; set;}
    public string Name {get; set;}
}

我从以下链接中得到了这个想法。

https://efpatterns.codeplex.com/discussions/282699

但未能成功实施。然后我开始学习装饰器模式和 DataAnnotation，因为 Product 实体上的 Auditable 属性的方式在 DataAnnotation 和装饰器模式中有些相似。所以我的问题是它们是一样的吗？如果它们相同，那么我将如何在我的项目中实现可审核存储库模式（更多链接）。

Answer 1

这不是四人组最初描述的decorator pattern。

装饰器模式是一种向现有类添加功能的继承技术。该模式通过创建一组子类来工作，每个子类在基类之上提供特定类型的功能。

然后通过将现有实例作为内部对象传递给子类实例来组合组合：

public class SecurityToken
public class ExpiringToken : SecurityToken;
public class RpcSecurityToken : SecurityToken;

因此，如果您想要一个远程令牌并在一段时间后过期：

var token = new RpcSecurityToken(new ExpiringToken(new SecurityToken("sds")));

你所做的只是用一个属性来装饰一个类，这不是一回事。

Answer 2

装饰器模式是一种将给定接口的基本实现作为扩展其行为而不修改原始实现的机制。

它类似于从基类继承，但是它具有更大的灵活性。例如，装饰器类可以应用于实现相同接口的任何其他类，没有限制只扩展单个基类。它们也可以链接在一起等等......

例如

public interface IThing
{
     void AMethod()
}

public abstract class ThingDecorator : IThing
{
    private IThing inner;
    public ThingDecorator(IThing inner)
    {
        this.inner = inner;
    }

    public virtual void AMethod()
    {
         this.inner.AMethod();
    }
}

从 ThingDecorator 继承并将您自己的扩展应用到虚拟 AMethod 将添加行为（装饰）传入的内部实例。由于内部实例与接口耦合，它可以是该接口的任何实现。

在您的示例中，您可以将 ThingDecorator 继承为 AuditThingDecorator，并在调用 base.AMethod() 之前覆盖 AMethod 并包含审核功能

这与仅将属性应用于类不同。我认为您正在尝试使用属性应用行为。如果存在容器或系统的其他部分可以读取属性并实际应用给定行为，则属性只能将行为应用于类。使用 DataAnnotations，还有其他类可以读取这些属性并应用行为（例如，在 ASP.NET MVC 中，DefaultModelBinder 使用某些属性在绑定模型时提供验证）。

这是一种 AOP（面向apsect 的编程）方法。应用它的一种方法（也是我倾向于使用的一种方法）是使用 Castle.Core 并创建可以自动实现接口方法或扩展虚拟方法并从正在拦截的方法/属性中读取属性的拦截器，然后应用行为：

http://docs.castleproject.org/Tools.DynamicProxy-Introduction.ashx

它们本质上都是给定类型的代理，但是上面的装饰器模式不是动态的，它们是在代码中创建的，AOP 方法可以在运行时应用行为。