command-pattern

I'm having a lot of problems lately because of what seems to be a bug in the MassTransit.UnityIntegration package, primarily due to the fact that registration names are not being considered. For instance, if I register my classes like this: var container = new UnityContainer() .RegisterType<Consumes<Command1>.All, Handler1>("Handler1") .RegisterType<Consumes<Command1>.All, Handler3>("Handler3"); A few lines later, I use the LoadFrom extension method to get the registered consumers in the container like this: IServiceBus massTransitBus = ServiceBusFactory.New(_sbc => { _sbc.UseBinarySerializer(

I have a list of jobs queued in the database which I need to read from database and execute them in parallel using threading and I have a list of command classes to execute each of those jobs all implementing a common interface (command pattern). but when I retrieve the pending jobs from the database, I will need to instantiate the right command object for each job something like this (in a factory class) ICommand command; switch (jobCode) { case "A": command = new CommandA(); break; case "B": command = new CommandB(); break; case "C": command = new CommandC(); break; } command.Execute(); Is

I am in the design process of an application, and I would like to use the command pattern for undo/redo purposes. I did some research into the command pattern but the only thing I don't get is: Should a command have the undo and redo methods, or should I make two separate commands, one for undo and one for redo, and call those from the main command itself? The command object itself should implement the undo / redo functionality. The commands are generally pushed and popped from a stack maintained by a command manager to implement multi level undo. When commands are executed they are pushed

I've been searching for quite some time for a good solution to the problems presented by the typical Repository pattern (growing list of methods for specialized queries, etc.. see: http://ayende.com/blog/3955/repository-is-the-new-singleton ). I really like the idea of using Command queries, particularly through use of the Specification pattern. However, my problem with specification is that it only relates to the criteria of simple selections (basically, the where clause), and does not deal with the other issues of queries, such as joining, grouping, subset selection or projection, etc..

I've read up on the Command Pattern, and I think I'm missing something. The Command object exists to abstract away the details of the Receiver object. It seems to me that we could simply stop here, and hold references to Command objects to execute the appropriate method at the appropriate time. Why, then, is the Invoker needed? What advantage does this additional indirection provide? We've already hidden the details of the Receiver behind the Command, what's the motivation for the Command to then be hidden from the client as well? Well, if you put it that way, it seems quite complex, but often

Once I had a discussion about design, relative to the command pattern. My peer stated that a command object should not return the status (successful, unsuccessful, and why) after the .execute() method is called. The reason is that you should not be concerned if the command gets executed or not, because the command must contain no state. You must however check after the invocation if the command had the expected effect. Another point he argued was that on the Gang of Four, the command pattern does not present this case (of returning status). I claimed the opposite point. The GoF does not

I am studying the command design pattern , and I am quite confused with the way of using it. The example that I have is related to a remote control class that is used to turn lights on and off. Why should I not use the switchOn() / switchOff() methods of Light class rather than having separate classes and methods that eventually call switchOn / switchOff methods? I know my example is quite simple , but that is the point. I could not find any complex problem anywhere on the Internet to see the exact usage of the command design pattern. If you are aware of any complex real world problem that you

I'm trying to design an async framework and wanted to know what people think are the pros/cons of the callback pattern vs the observer pattern. Callback pattern: //example callback public interface Callback{ public void notify(MethodResult result); } //example method public class Worker{ public void doAsyncWork(Callback callback){ //do work callback.notify(result); } } //example observer pattern public interface EventListener{ public void notify(MethodResult result); } public class Worker{ private EventListener listener; public registerEventListener(EventListener listener){ this.listener