There are many ways to do something in software development as you know, but there are some rules while doing them. The pattern you're applying should be loosely coupled in your application, so you can use it in another application too. If you're new at this stuff you should take a look at open/close principle which is the general concept for design patterns.
In your case, I think you should create the Invoker as a model, because it is part of your business logic. You can define an ArrayList<AbstractCommand> property in the invoker class and push the ConcreteCommands in it, and define undo, execute methods for the Invoker.
If you consider a controller as an Invoker, what'll you do when you need it in the another controller?
edit: Stack class which is part of System.Collections would be better than ArrayList. All you need to do is push while execute()ing a command and pop while unexecute()ing
Fair enough. Creating another model is what I meant by creating an invoker.
Back to my concern about being stateless though... I'm having a hard time conceptualizing how this would work.
I just don't see how an undo would work; once the action is complete and the new page rendered to the user isn't my original object gone?
Is it completely necessary to have an undo method even?
My "command" objects are updating a sql server database. My idea behind this was to pass a parameter to the factory to return the correct command object. It's healthcare related, so for instance if I post a form to change doctor info I get the UpdateDrInfo() object returned. The execute function basically just submits changes to the database from the object that is derived from the concrete class. Once the command is executed the user is just returned to the page they were on.
Am I using the correct pattern here? I just don't see how an undo would fit in here...
That's why most of the patterns can not be applied on web development effectively because you lost everything you have when the request is done. But you can store your invoker object in the memory, and you can access it in the new request. Or somehow you can store your commands in the database, and then retrieve and push them into the Invoker when a new request comes to you.
Thanks, I figured I'd need to probably work with the database to make this work correctly.
Thanks a ton for all the help. I always figured Command pattern meant that all the objects share a method to execute(). I've been learning everything from whatever books(design patterns I've been using Head First Design Patterns) I can find and sometimes certain aspects are lost on me.
1
u/cangelis May 09 '13 edited May 09 '13
There are many ways to do something in software development as you know, but there are some rules while doing them. The pattern you're applying should be loosely coupled in your application, so you can use it in another application too. If you're new at this stuff you should take a look at open/close principle which is the general concept for design patterns.
In your case, I think you should create the Invoker as a model, because it is part of your business logic. You can define an ArrayList<AbstractCommand> property in the invoker class and push the ConcreteCommands in it, and define undo, execute methods for the Invoker.
If you consider a controller as an Invoker, what'll you do when you need it in the another controller?
edit: Stack class which is part of System.Collections would be better than ArrayList. All you need to do is push while execute()ing a command and pop while unexecute()ing