+972 52-548-6969
What lurks in the dark corners of the Castle
![130069032_4ec501df3f[1].jpg](http://72.15.222.55/Blog/images/72_15_222_55/Blog/130069032_4ec501df3f[1].jpg)
I had a chat with a pal of mine recently, about why he would recommend working with Web Forms over MonoRail.
The short answer was that he didn't want to end up with an ungooglable exception. The reasoning is that there isn't any nook or crany in Web Forms that hasn't been discovered, talked about, solved, and most importantly than all, indexed by Google.
I don't agree with this approach, but I recognize that this is a valid way of operating. The major reason that I don't agree with this is that I have run into issues with ASP.Net that were essentially un-googlable and undebuggable.
Castle currently has four or five major projects ( I was surprised myself, I expected it to be at least a two digit number ).
Learning each of them by itself is not hard, at least not in the "good enough to work with and learn on the job". Getting to a master level isn't any harder than in any other technologies, it just takes time and experiance.
There are certainly quite a few more experts in Web Forms than about MonoRail, but I find that I have to struggle to get what I want a lot less in MonoRail, and I get into far less situations that require the use of an expert. One of the core principals of Castle is that it should be simple. And by simple I don't mean the implementation, but the usage. It takes a minute to explain how SmartDispatcherController works, and any programmer can grasp how it can be used from three sentences. The implementation of the Smart Dispatching is quite complex, but you never need to see it.
One of the main differences between OSS and Commercial software is the amount of time that is invested in the frills. Active Record and NHibernate has a designer, which is nice, but it is not a level 1 priority to any of the people using either Active Record or NHibernate. The reason is that both those frameworks were built knowing that a designer is not something that you should need in order to work with them.
WebForms has a huge task on developing custom controls. Not only must the control play nice in the page life cycle dance, they also need to jump through many many hops in order to work in the designer. MonoRail's ViewComponents, on the other hand, are literally HTML generators, with no extra complexity on top of them. Again, the simple outward interface makes it easy to work with the frameworks.
Some of those things require a fair shift in thinking, but once you get comfortable with MonoRail, there is no steep learning curve until you get to Windsor integration, which simply require that you understand how IoC works. Instead, there is a lot of discovery going on, mostly with helpers, filters, and such.
Now, Castle's is built of many projects that are designed to be used independantly. But, they are also designed to work together. This means that the Whule Is Truly Greatly Than The Sum Of Its Parts. Taking Active Record, MonoRail and Windsor for a spin is a fun ride, but that require that you understand all three, and their interactions. The nice thing about it is that it is not that big of a jump from knowing them to working with them together.
To summarize, a basic working knowledge of Castle is probably something that you would want to have before you would start building applications with it. There are numerous getting started guides out there right now, which can help you grok what you are trying to do. I don't believe that you need an expert on hand to solve problems, looking at the forums or asking in the mailing list will usually get you the answers that you seek. There is also a lot of effort in making the exceptions detailed and self explenatory.
Naturally, I am biased, so I am not sure that my opinion in this matter counts, what do you think?
Comments
The thing about Castle is that the reasons for not using it are far more visible than the advantages it offers.
Once the majority of .NET developers have had a broader exposure to similar technologies (like the MVC Framework we've been hearing about, the Entity Framework and the more advanced features in EntLib 3.0) I believe only then will Castle be taken into consideration as a better alternative - if it stays better that is. There's a thing about developers accepting a marginally better solution but not a complete new one.
I personally have not used Castle in production, only in a small application. There were some things that I didn't really love, like the whole FormHelper/HtmlHelper routines and redirections if you use url rewriting. I expected a much more html-ish way of describing the forms. Overall, I liked it a lot.
And yes, I agree with you on the part about the issues with ASP.NET that are un-googlable.
First I used NHibernate. Then I got into Castle. And finally, I tried Monorail. It went that way, because I got to know technology X by investigating technology Y and bumping into common practices.
I did run into an issue with Monorail, or actually Castle, that I would not have been able to address if I hadn't done Castle before. It did pop up at Google for 1 hit or so, but still, it gave me headaches. Luckily, my code had nothing to do with a deadline and the Castle bug got fixed (AmbiguousMatchException). So in that very case, one would argue against Castle for not being "mature" enough. But then again, as you say Ayende, there's an order of magnitude issues with ASP.NET that way. Maybe it's because I'm better in ASP.NET than Monorail, but I'm confident I can get my tasks done in ASP.NET with the knowledge I currently have. So there's no commercial point for us diving into Monorail, seeing the online resources you have at hand for ASP.NET. Still, the thing can sting like a ray and throw the undebuggable at you.
@Eugen:
If I can summerise your comment: you say that using the Castle stack is "better" (or at least "more advanced") than the out-of-the-box MS stuff. We should wait for MS do catch up, and only then consider weather to use MS stuff or Castle.
And I ask, why one should wait? I'd say use Castle now, and when MS will catch up, then consider the MS alternative.
I did the same as Grimace, but the main problem I've had is the lack of maturity in the documentation.
I'd also kill for an offline version of it since there have been several times over the last week where my team has been trying to grok the whole shebang but the site's gone offline and they're stranded. Maybe one exists and I've missed it?
Overall, however, I'm finding the Windsor/Monorail suite to be a vary productive environment to work in.
I used to do a lot of Web Forms development and it just seems that after every single project I'd hate it more and more. There would always be at least one issue, especially as the project complexity increased, that would have me digging through the Web Form code in Reflector to see just what the heck was going on. I knew what I wanted my code to do, I knew how it should function, but more often than not, especially with custom controls, Web Forms would get in the way. Between view state issues, strange page life cycle problems (especially with databinding), and whacky rendering (especially when shooting for XHTML compliance) ... I had it up to here with Web Forms.
Now, with MonoRail, 9 times out of 10 I get exactly the result I was going for with a lot less hassle, which saves me time and my company money. Sure, I've run into a few issues with MonoRail but for the most part those issues have been easily fixable either by searching on the forums or doing a really quick search in Reflector (the innards of MonoRail my be complex but not near as ugly as Web Forms). I don't think I've ran into any issues that I wasn't able to fix in a couple of hours. I can think of at least one time, with Web Forms, where I was troubleshooting an issue with a custom control that took me a couple days to figure out a nice solution for.
As for how I came about to use MonoRail... Ruby on Rails :P I've always enjoyed coding with C# and .NET (and thought WebForms was fine) but when Ruby on Rails came along, I was torn. So many new good ideas, patterns and practices. So, I started searching and stumbled upon Castle ActiveRecord and then MonoRail. The rest was history.
Also, for what it is worth, my team and I are going to be releasing into production our company's customer portal which is developed entirely on MonoRail (and ActiveRecord). It will be used by several thousand customers to get their product downloads, documentation, licenses, etc. Overall, we are quite happy with MonoRail. I was able to sell them on it before we started the project and am quite glad of that.
@Symon Rottem:
The whole castle site(minus the wiki) is available offline thru the site's subversion repo : https://svn.castleproject.org/svn/castle/site/website/castle
hth
I started looking for an Ioc container implementation a while back and looked a Pico, Spring and Microsoft's ObjectBuilder. I thought ObjectBuilder should be the way to go since we had already standardized on the Enterprise Library. The more I read about ObjectBuilder the more I realized that MS really doesn't care about giving us a well documented Ioc core or container. I started learning about Windsor and have a real interest in learning the principles of the MicroKernel. Windsor really does seem much easier to get up and running with than any other Ioc container implementation I've seen out there.
I don't develop web apps but Ruby/Rails also lead me to the Castle project.
On the controls:
Perhaps somehow we have a user contribution section for ViewComponents.
Make it easy to plug those in.
After awhile, a good build up of ViewComponents could offset the controls aspect, a part I've struggled with.
Personally (I'm lazy I guess), I'd love to see some of the Ajax functionality implemented as ViewComponents. ie. an equivelant of the 'UpdatePanel' as a ViewComponent.
Add the component, set a few properties and bingo , you have Monorail and an Ajax enabled ViewComponent
The comments I've often run up against when proposing a solution like MonoRail are more in tune with the broader concerns of services/consulting based work.
Let's say I'm contracted for 6 months to build my client a MonoRail application and it works great. We ship on time, on budget, and the users are very happy. I get paid at the end of the engagement and go onto another project.
Fast forward 6 months...I am no longer on the client's payroll and they want an enhancement. How easy it going to be for them to find a MonoRail expert who can not only understand the framework, but also extend an existing solution?
Does using MonoRail automatically lock you into consulting projects that have an ongoing maintenance agreement? This is something more service-based shops shy away from.
I'd like to hear other's thoughts/experiences about this.
I've haven't taken much more than a cursory look at MonoRail, but you can count me in as one who is frustrated with webforms.
I think what keeps me from moving forward with MonoRail is the view aspect. I find myself put off by the NVelocity and Brail view engines because they feel "messy" to me. They remind me of classic ASP or PHP. I think that the HTML abstraction that webforms creates is not necessarily a bad thing. The problem is the abstraction of state, and that is where things get ridiculously ugly sometimes.
I think a view composed of markup similar to webforms would be very appealing. It would provide a nice abstraction with a declarative way to compose the page with reusable components. This would also allow a code behind to code against the markup. No life cycles, no view state, just a simple control tree created through markup/code that will render the view.
I looked into attempting this myself, but I'm short on time and, frankly, lack the required knowledge of MonoRail and the ASP.NET buildprovider model to pull this off, although I haven't given up yet.
RE: I think a view composed of markup similar to webforms would be very appealing.
I personally don't find that very appealing. I've always found Web Forms markup to be quite messy because it is essentially two different kinds of similar markup in the same file. On complex pages it starts to look less like the HTML you want the page to render and more like tag soup.
@Eugen,
I disagree, I see no reason to stick behind in the safe enclosure when I can have much more fun and be more productive using existing tools.
@Steve,
There is a TODO on my list for building a project of user contributed components, I hope to have it by the end of the week.
Update Panel is not really applicable for MonoRail because the way you architect your UI is different, instead of postback model, what you usually handle is a a sub view and a Ajax.Updater that uses that.
@Steve,
There is a TODO on my list for building a project of user contributed components, I hope to have it by the end of the week.
Update Panel is not really applicable for MonoRail because the way you architect your UI is different, instead of postback model, what you usually handle is a a sub view and a Ajax.Updater that uses that.
@Karthik ,
Not different in any way than using anything that is not in the box.
I have heard those concerns before, and my response was: Are you using any 3rd party items? The answer was invariably yes.
It can be argued that using a 3rd party code (or even something remotely unfamiliar from the first party), will leave you in the same shape.
Build a solution with MR doesn't mean that you are stranded or stuck to one supplier. It doesn't take long to understand how MR works, and from there it is fairly easy to move forward.
A MonoRail expert is not require, a developer with an ability to learn is the only thing that you need.
I had the chance to see quite a few in-house frameworks, allow me to assure you that it usually takes a lot more time (and there is a lot less documentation) to learn those than any external factors.
@Symon,
We now have a wiki at:
http://using.castleproject.org/
Please contribute with what you can, at least in outlining the parts that are missing, in your opinion.
@Matt,
I understand that this can be a big jump, but please try it on a simple project.
The reason that we have the view engines structure this way is because it is the most explicit way to express what we want to generate, HTML.
It is clearer when you see what is there.
The "abstraction" that Web Forms provide is often harmful, not just because of the state issues.
There are a lot of people that seem to get hung up on the view stuff, mostly because of bad memories from ASP.
But the main difference here is that you have proper seperation, ASP was great for HTML generation, it was just bad for most of everything else.
I´m using Monorail for seven months and I love it because of the simplicity. I aways post issues in my blog trying to convince the people to learn about Castle and Monorail. But I think is the big step for the .NET Community adopting this great idea, mainly here in Brazil.
Comment preview