Incremental development with Monorail

April 23rd, 2008

Just bumped into this. Great work, Ben.

Just personal preference-wise:

- I’d prefer not to use the BaseControllerTest class
- Instead of writing the form tags, I’d use the form helper: $Form.FormTag(“%{action=’save’}”) and $Form.EndFormTag(). Then you take advantage of automatic form field validation if you want.
- For actions that change things, I’d use [AccessibleThrough(Verb.Post)]
- I’d configure Windsor through code
- The mapper/wrapper sounds like iBatis. Why not using Repositories with Castle ActiveRecord?
- Instead of DTO you could use the domain class as a prototype. I think that simplifies the code.

The cool thing is that Ben knows TDD. He creates a dummy implementation, get the test passing, corner it, triangulate it, and then is forced to get rid of the dummy implementation. That’s the essence of “test-driven”.

The series is also a good way to compare MonoRail with MS MVC. The goals are the same, they just provide different ways to get the same result, up to you to use the one you like the most.

3 Responses to “Incremental development with Monorail”

BenL Says:

Thanks for the comments/link Hammett. I’ll incorporate your suggestions, most of them certainly are things that I have added during development of other MR solutions I’ve been involved in.

I’d be interested in hearing your preferred approach to testing controllers?

With regard to the mapper stuff, I like to map from screen-bound DTO’s to domain objects in my services, my domain objects will use AR when they’re implemented for sure.

hammett Says:

Ben, those are mostly personal, so dont worry. I’ve blogged on approaches to test MR controllers, you might want to check the blog history.

A'braham Barakhyahu Says:

This is a good series. I think I’ll run through this one this weekend.

Leave a Reply