I'm done using Cairngorm. It's just too much boilerplate code to write. Today I started to create my own micro nano-framework called GrainCorn. As the name implies it's quite close to Cairngorm. Or close at least when it comes to best practice rules. There's a huge difference in the amount of code you have to write. And that got me worried a little. Is there some deeper meaning to the Event-Controller-Command relationship that I'm just not getting?
In Cairngorm when you want to create a new Command you have to do three things: Create the Command class, register it in the Controller and create a Event class which eventually fires the command. Now, what's the reason to separate the event from the command, since the event always fires the command to which it has been registered, i.e. the event transports data (attributes) into the execute-method of the command.
After some thinking I came to the conclusion that it's easier to bend the spoon itself rather than to bend yourself around the spoon.
GrainCorn gets rid of the Event, and actually the Controller as well. That leaves us with one Command-class to create for every feature we'd our application to have. You issue a command by simply instantiating a new instance of a command, passing any parameters in the constructor:
It's not necessary to store the command in a variable, since registering itself with the framework is handled by the command itself (every command extends GrainCornCommand). Also no controller is needed to bind Events to Commands, since we've removed Events altogether.
Any thoughts? Am I missing something?
Comments
I was always under impression that you could register more than one command to listen to events but now I had some time to try it out and indeed it's not even possible.
I'm not sure I understand this limitation; I was under impression that Event is something that happens as a result of user gesture and FrontController then defines what Command(s) are notified about this event.
Posted by: Tero Pikala | 7 Aug 2007 13:11:39
Well, it kinda makes sense. For every user gesture there's one command. If the gesture implies that multiple commands be run, then the command that gets executed for the gesture can conjure other commands by dispatching events.
But I still don't get why Cairngorn has events in the first place.
Posted by: Tuomas Artman | 7 Aug 2007 19:40:11
That seems like a reasonable approach. It certainly cuts down on the code required to run that command.
One comment:
For developers that are currently using Cairngorm, it may seem a bit odd that creating a new command actually executes it. You might want to consider using: new LoginCommand().execute(username, password), though that requires more typing.
Derek
Posted by: Derek Wischusen | 7 Aug 2007 19:57:39
Quite often I listen (add a listener)to the CairngormEventDispatcher and handle events this way.
These events are not registered with the front controller and may not even be subclasses of CairngormEvent. I only use CG events for model updates that can be made from more than a single location and server side calls are also handled by CairngormEvents. I use events on form fields to update the model for attributes such as firstName of a Person Object. As it will only ever be updated from one place there is no need to build a custom event type for this situation IMO.
How would this be possible with your implementation?
Perhaps looking at one of the other MVC frameworks would be a good idea rather than writing a custom one.
The benefits of being used/tested by many other developers are great and also it makes it easier to build a team of developers that have experience with the MVC framework being used.
cheers,
Posted by: shaun | 8 Aug 2007 04:55:49
I'm not certain I understand the question. In my mind, the CairngornEventDispatcher acts closely with the FrontController, dispatching events that are meant to invoke a command. I've not used it to dispatch non-command targeting events.
Anyhow in Graincorn you can still add event listeners to all commands. All commands subclass the GrainCorn command class and automatically register themselves with a central dispatcher, so it's quite easy to listen. The only difference is that you're not listening to events, but commands that are triggered.
I also thought of having the commands execute, but opted otherwise simply because I didn't want to write the extra code. Now I'm again leaning towards using the execute-method, since that is the requirement to be able to handle chained commands.
Posted by: Tuomas Artman | 8 Aug 2007 21:30:18
Where can I download GrainCorn?
Posted by: soknet | 3 Nov 2007 16:17:09
i want grain corn. where can i get it? come on!
Posted by: cole | 21 Nov 2007 06:05:13
There's not much to download;) GrainCorn is more an design method than a codebase. Where Cairngorm has about 300 lines of code, GrainCorn has about 20, and it's all just in the Bussiness logic.
Posted by: Tuomas Artman | 21 Nov 2007 08:30:06
respected experts,
i dhaval shah, want to know that can we use more than one entity or command class in controller in spring(java)..if you find the way than please tell me..
thanks..
Posted by: dhaval | 4 Apr 2008 09:07:02
Hi,
I think that perhaps the point is being missed slightly. Cairngorm is a best of breed, block and tackle framework where the Adobe guys have ported many of the proven patterns from J2EE. If Cairngorm seems like overkill for your project its probably not big enough to warrant use of Cairngorm and your GrainCorn idea is perfectly adequate. I have implemented the Cairngorm framework at work and when you have vast projects and 12 developers all trying to reinvent the wheel you start to understand the benefits even if it is as you say - a lot of boilerplate - sometimes thats really important. The reason for the separation between the event and the command is granularity and encapsulation - every class performing its own specific job, and only that. It also means that you can listen for these events independently of the front controller for instance you might want a progress bar you sit on your LoginCommand while it is executing - sure there are other ways to do that but the Cairngorm way ensures a consistent pattern. How would you listen to your LoginCommand does it extend event or does it implement IEventDispatcher the other way around? In a large development team knowing the implementation pattern is a safety net against producing what I call Mandelbrot code.
All in all any MVC is good MVC and patterns are important every developer should learn thier value.
Regards
Luke Lincoln
Senior Software Developer - Iron Mountain UK
Posted by: Luke | 7 Jun 2008 13:12:47
