What is the difference between ComponentModel.DataAnnotation and decorator pattern.?

Question

I was implementing repository decorator pattern on my project as:

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

I got this idea from the following link.

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

But couldn't successfully implemented. Then I start learning about decorator pattern and DataAnnotation because the way Auditable attribute on Product entity is somewhat similar in DataAnnotation and decorator pattern. So my question is are they same thing.? If they are the same then how would I implement Auditable repository pattern (more on link) on my project.

My understanding is that the "Decorator" (normally) adds functionality, whereas attribute's are (normally) intended to add meta-data which is then interpreted / used by arbitrary functionality. Obviously there are exceptions (such as MVC filterAttribute) — Andrew Hewitt, Feb 25 '15 at 10:14
Repositories aren't a fantastic way to abstract EF. Suggest looking at [Unit of Work design pattern](http://www.codeproject.com/Articles/581487/Unit-of-Work-Design-Pattern) — Inspector Squirrel, Feb 25 '15 at 10:24
But the static class TypeDescriptor in DataAnnotation provide similar functionality as Decorator pattern provide. — user3578682, Feb 25 '15 at 10:36

James Simpson · Answer 1 · 2015-02-25T10:30:04.430

The decorator pattern is a mechanism of taking a base implementation of a given interface as extending its behavior without modification of original implementation.

Its similar to inheriting from a base class, however it has more flexibility. For example, a decorator class can be applied to any other class that implements the same interface, there is no restriction to only extending a single base class. They can also be chained together etc...

e.g

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();
    }
}

Inheriting from ThingDecorator and applying your own extension to the virtual AMethod will add behavior (decorate) the inner instance that is passed in. As the inner instance is coupled to an interface it can be any implementation of that interface.

In your example, you could inherit ThingDecorator as AuditThingDecorator, and override AMethod and include Audit features before you call the base.AMethod()

This is different to just applying an attribute to a class. I think you are trying to apply behavior with an attribute. Attributes can only apply behavior to the class if there is a container, or some other part of the system that can read them and actually apply given behavior. With DataAnnotations, there are other classes that read these attributes and apply behavior (for example, within ASP.NET MVC, the DefaultModelBinder use some of the attributes to provide validation when binding the model).

This is a AOP (apsect orientated programming) approach. One way to apply this (and a way I tend to use) is to use Castle.Core and create interceptors that can automatically implement interface methods or extend virtual methods and read attributes from the Methods/properties that are intercepting, and then apply behavior:

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

They are both essentially proxies of a given type, however the Decorator pattern above is not dynamic, they are created within code, and the AOP approach can apply behavior at runtime.

I appreciate your kind answer.But what I was trying to implement is contained in the link provided in the post. It says, if we use Auditable attribute on any entity like Product class then we'll get the columns Id and Name from Product class and columns CreatedBy, Created, UpdatedBy, Updated from the Auditable class in database using EF code first.Where as the name of table will be Product. But what was getting only column Id and Name. — user3578682, Feb 25 '15 at 14:20
The examples use AOP technique. From the link you posted, 1) you need to decorate the class with [Auditable] and 2) you need to make sure you wrap your repository with the AuditableRepository (in example) — James Simpson, Feb 25 '15 at 15:20

score 0 · Answer 2 · answered Feb 25 '15 at 10:26

That's not the decorator pattern as originally described by the Gang Of Four.

The decorator pattern is an inheritance technique to add functionality to existing classes. The pattern works by creating a set of subclasses which each provide a specific type of functionality on top of the base class.

Then you compose a combination by passing the existing instance as inner object to a subclass instance:

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

So if you would like to have a token which is remote and will expire after an amount of time:

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

What you do is to just decorate a class with an attribute, which not is the same thing.

so if it not decorator pattern described by Gang Of Four then what is correct way of implementing repository decorator pattern with entity framework. — user3578682, Feb 25 '15 at 11:55

What is the difference between ComponentModel.DataAnnotation and decorator pattern.?

2 Answers2