Zen and the art of Castle maintenance

Hi Hammet,

thanks for posting the link back to the talk. Some things that you have raised here are addressed in the talk as well (ppt cannot really have all the details of a two hour talk), but the video is still not yet online. It takes Skills Matter about two weeks to publish the podcast.

Regarding the RC versioning, I know about your reasons, and that part of the talk was exactly about how Castle RC versions are stable enough to be used in production. I guess that it may be a cultural thing, but from the perspective of the UK market, it would make much more sense if rc2 and 3 were versions 2.0 and 3.0. People here are a typically reluctant to base something that should go into production on a release candidate.

ARMediator: Did not know about this — I’ll make sure to mention this next time. There was quite a lot of interest for this talk, so we may be doing another one (probably more focused on ajax+monorail+windsor) in June.

Monorail - Layouts: IMHO, i could have reused the code a lot better a few times if I could have specified layout and area from outside (config file) rather then in the code.

MonoRail (-) : Hashmap for view properties - in the talk, I suggested that this may seem like giving too much freedom, but that from my experience people end up creating monstrous objects to pass all properties to strongly typed MVC engines, or just give up and use a hashmap. I suggested complementing the hashmap approach with unit tests for controllers to verify what gets put in the hashmap, and that should provide enough security.

MonoRail (-) : Windsor Integration a bit too complicated: unfortunately, we did not get to this part in the talk at all (maybe we’ll do it in the next one). Maybe things have changed since the last release, but with RC3 I had to start up a rails facility and then register all controllers as components; if I am not doing something wrong, controllers have to be registered as components from the code, the config file seems to only accept parameters for already registered controllers. And, even when controllers are registered through the code, the assembly still has to be specified in the config file for everything to work correctly.

This breaks the convention over configuration principle quite a lot, and requires redundant config (assembly specified in the monorail section, but also controllers registered in the code). If we use monorail without windsor, then controller classes get picked up automatically, we can just add new controller classes without changing some meta-config class or anything like that. When windsor+monorail is used, we have to remember to update the application class as well.

I guess that it would not be too hard for the rails facility to just run through the assembly specified for monorail and initialise all controllers and components, and it would make the integration much easier to use.

ARMediator: I second that motion. I didn’t know about it either. I’d noticed it in the documentation (not clickable), but not thought enough to go diving into the tests to find out what it was.

Now I know to go check it out! Thanks!

Hmmm… the ARMediator looks interesting, but judging from the very sparse documentation, we would be going down the Repository route, which I do like when I work with more complex domain models. I’ve been using NHibernateRepository implementations for a few DDD projects now. I’m not sure what additonal value a repository implementation with ARMediator brings compared to an NHibernateRepository, other than offering an easier way of specifying the OR mappings.

For our current project I thought we’d go down the AR road. Reason: domain model is not too complex and actually quite focussed around CRUD functionality anyway. But reading your comments on AR, I’m wondering if I made the right choice…

Can you comment on this?

Thanks!

Pascal.

ARMediator is dead simple:

1. Write your classes without a AR base class.
2. Instead of Entity.Xxx use ActiveRecordMediator.Xxx

-Markus

Pascal,

If you are already using the NHibernateRepository from Rhino Commons, you can swap that for the ActiveRecordRepository, which is in essence a “repository implementation with ARMediator”. Both implement IRepository.

Recenty a patch i made was applied to the Castle trunk, which added ActiveRecordHooksValidationBase. If you want, you can inherit your entity classes from that. Then you still have the goodies from the automatic validation in MonoRail, but without all the public Save(), Find() etc methods.

The additional value for me is:
- easier mapping, what you said
- easy [ARDataBind] and [ARFetch] for MonoRail with (simple) validation

I hope this is of any help,
Alwin

Alwin,

Thanks a lot for your helpful feedback! I didn’t even consider the Monorail benefits, since I have not used MR in combination with ActiveRecord thusfar. So thanks for pointing that out. Also thanks for pointing the ActiveRecordHooksValidationBase out to me. I’ll keep that one in mind.

In general, my bias is: if it ain’t ActiveRecord (because we use a repository), then let’s not call it that. It just makes stuff all the more confusing and in software development we can easily do without additional confusion!

But now that I have a better view of the practical benefits, I feel I can make a more solid decision.

Thanks again!

Pascal.

Hammett,

How about moving to distributed versioning system (e.g. git, mercurial, bzr etc). Then it will be more easier for you to focus on your interest and let those who love other part to move on and make improvement to monorail and publish theirs.

Honestly, I believe what we currently has should have been a release by itself. Maybe we should have a release date and gather all the resources to achieve that date. Without a specific release date, I’m afraid, it’ll always be an RC.

Yeah you can use Castle AR without really using the ActiveRecord pattern

Alwin,

NICE! I missed the ability to subclass on ActiveRecordHooksValidationBase! Nice and significant strategic strike.

Kind Regards,
Damon Carr

[…] has a post where he, among others, […]