Implementation of command pattern with Asp.Net MVC

[A'braham Barakhyahu]

Anyone have a good sample of the command pattern in a ASP.NET MVC?  

--
A'braham Barakhyahu
Client-Side & Server-Side Developer

http://www.linkedin.com/in/AbrahamBarakhyahu
phone: (804) 592-1392
efax: (815) 425-0569

[Justin Etheredge]

I'm not sure exactly what you are asking, the command pattern is usually very simple, just an interface called something like ICommand with a single method which executes the command. Something like:

public interface ICommand{

  void Execute();

}

Then you can have any number of implementations of this interface to execute said commands.

Are you looking for something more like a command queuing or processing example?

-- 

Justin Etheredge

Company: http://www.ecstaticlabs.com

Blog: http://www.codethinked.com

Twitter: @JustinEtheredge

--
You received this message because you are subscribed to the Google Groups "Richmond Software Craftsmanship Group" group.
To post to this group, send email to RS...@googlegroups.com.
To unsubscribe from this group, send email to RSCG+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/RSCG?hl=en.

[A'braham Barakhyahu]

The few I've seen have been mixes of queuing or messaging with the command pattern.  Some have a factory, some have the extra logic for undo (which is not so easy with web apps).  I guess I wondering if a command factory or handler is needed, or should one have it more explicit, defining the commands the controller needs (which will be injected).

[Jonathan Pryor]

On Mar 27, 2012, at 2:15 PM, Justin Etheredge wrote:
> I'm not sure exactly what you are asking, the command pattern is usually very simple, just an interface called something like ICommand with a single method which executes the command. Something like:
>
> public interface ICommand{
> void Execute();
> }

Out of curiosity, why use an interface if it has only one method? Why not System.Action?

Now, if there were also an Undo() method or something, an interface would start to make sense to me...

- Jon

[Al Tenhundfeld]

+1  I was wondering the same thing; needing to serialize the command (across an AppDomain or something) would be another reason for an interface/class.

Al

[Justin Etheredge]

The main reason is that the command pattern always works the same way when you execute it, but creating the class is usually where the implementation differs. So I would pass additional info into a constructor, or set properties when I create the command, then later it would be executed. If I were to implement it as a simple System.Action then breaking the command apart for readability, or passing in state in a structured way would be harder.

On top of all that, using an interface helps create a "seam" for testing.

[Al Tenhundfeld]

Most of the time when I used the command pattern, I was really trying to use functional programming ideas, but your points all make sense.

It's been a long time since I've purposefully thought about design patterns in C#; I just have my favorites and use them as needed. However, getting more into Ruby/Rails lately has awakened that part of my brain as I think about patterns involving mixins, delegation, open classes, etc. It's really fun to have that beginner's mind . 

Al

[Jonathan Pryor]

On Mar 27, 2012, at 3:50 PM, Justin Etheredge wrote:
> The main reason is that the command pattern always works the same way when you execute it, but creating the class is usually where the implementation differs. So I would pass additional info into a constructor, or set properties when I create the command, then later it would be executed. If I were to implement it as a simple System.Action then breaking the command apart for readability, or passing in state in a structured way would be harder.

I'm not sure I buy that; an Action could refer to any instance method taking no parameters, so this would be entirely valid:

Action command = new WhateverType (constructorArgs) {
Property1 = Value1, /* ... */
}.Execute;

OK, it would probably be better to split that up: ;-)

var c = new WhateverType (constructorArgs) {
Property1 = Value1, /* ... */
};
Action command = c.Execute;

Either way, we have an object that contains all the state you want. You're just using an Action to refer to the command instead of some concrete interface. I don't see a huge difference either way, and I find delegates more easily composable than interfaces.

> On top of all that, using an interface helps create a "seam" for testing.

I'm not entirely sure what "seam" testing is, but I don't see why delegates would make this any harder.

- Jon

[Jonathan Pryor]

On Mar 27, 2012, at 3:47 PM, Al Tenhundfeld wrote:
> +1 I was wondering the same thing; needing to serialize the command (across an AppDomain or something) would be another reason for an interface/class.

I don't buy this either; passing an Action across an AppDomain boundary will still result in serializing the referenced class instance and loading the containing assembly into the new AppDomain. It's not any different than passing an instance across an AppDomain boundary, as you still are passing the instance across the boundary.

- Jon

[Justin Etheredge]

Yeah, I think you're correct. I think I would still go with an interface because it makes the pattern more apparent. For example, when this pattern is implemented, you usually have a set of commands. These are represented as classes, and it is nice to have the interface implemented on those classes so you can tell exactly which method is the entry point, and you know what those classes are used for. Also, if you're using an IoC container you can load command types based on the interface, whereas if you're just using random methods on classes, you have no easy way to wire it up dynamically.

But yes, you're correct in that I was thinking about the action wrong, in that it is very easy to just assign a method from a class to an action and then pass that around.