﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Samir Mamude commented on What lurks in the dark corners of the Castle</title><description>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.
  
</description><link>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment18</link><guid>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment18</guid><pubDate>Wed, 09 May 2007 02:21:02 GMT</pubDate></item><item><title>Ayende Rahien commented on What lurks in the dark corners of the Castle</title><description>@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.
</description><link>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment17</link><guid>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment17</guid><pubDate>Tue, 08 May 2007 20:20:15 GMT</pubDate></item><item><title>Ayende Rahien commented on What lurks in the dark corners of the Castle</title><description>@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.
</description><link>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment16</link><guid>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment16</guid><pubDate>Tue, 08 May 2007 20:15:53 GMT</pubDate></item><item><title>Ayende Rahien commented on What lurks in the dark corners of the Castle</title><description>@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.
</description><link>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment15</link><guid>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment15</guid><pubDate>Tue, 08 May 2007 20:14:35 GMT</pubDate></item><item><title>Ayende Rahien commented on What lurks in the dark corners of the Castle</title><description>@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.
</description><link>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment14</link><guid>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment14</guid><pubDate>Tue, 08 May 2007 20:05:29 GMT</pubDate></item><item><title>Ayende Rahien commented on What lurks in the dark corners of the Castle</title><description>@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.
</description><link>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment13</link><guid>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment13</guid><pubDate>Tue, 08 May 2007 20:05:29 GMT</pubDate></item><item><title>Ayende Rahien commented on What lurks in the dark corners of the Castle</title><description>@Eugen,
  
&gt; the reasons for not using it are far more visible than the advantages it offers.
  
  
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.
</description><link>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment12</link><guid>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment12</guid><pubDate>Tue, 08 May 2007 20:02:21 GMT</pubDate></item><item><title>Michael Morton commented on What lurks in the dark corners of the Castle</title><description>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.  
</description><link>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment11</link><guid>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment11</guid><pubDate>Tue, 08 May 2007 20:01:02 GMT</pubDate></item><item><title>Matt G commented on What lurks in the dark corners of the Castle</title><description>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.
</description><link>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment10</link><guid>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment10</guid><pubDate>Tue, 08 May 2007 16:07:13 GMT</pubDate></item><item><title>Karthik commented on What lurks in the dark corners of the Castle</title><description>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.
</description><link>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment9</link><guid>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment9</guid><pubDate>Tue, 08 May 2007 15:31:02 GMT</pubDate></item><item><title>Steve commented on What lurks in the dark corners of the Castle</title><description>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
</description><link>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment8</link><guid>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment8</guid><pubDate>Tue, 08 May 2007 13:22:40 GMT</pubDate></item><item><title>Mark Lindell commented on What lurks in the dark corners of the Castle</title><description>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.
</description><link>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment7</link><guid>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment7</guid><pubDate>Tue, 08 May 2007 11:36:09 GMT</pubDate></item><item><title>bonskijr commented on What lurks in the dark corners of the Castle</title><description>@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
</description><link>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment6</link><guid>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment6</guid><pubDate>Tue, 08 May 2007 11:33:45 GMT</pubDate></item><item><title>Michael Morton commented on What lurks in the dark corners of the Castle</title><description>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.
</description><link>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment5</link><guid>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment5</guid><pubDate>Tue, 08 May 2007 10:41:22 GMT</pubDate></item><item><title>Symon Rottem commented on What lurks in the dark corners of the Castle</title><description>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.
</description><link>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment4</link><guid>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment4</guid><pubDate>Tue, 08 May 2007 10:01:34 GMT</pubDate></item><item><title>Ken Egozi commented on What lurks in the dark corners of the Castle</title><description>@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.
  
</description><link>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment3</link><guid>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment3</guid><pubDate>Tue, 08 May 2007 09:47:33 GMT</pubDate></item><item><title>Grimace of Despair commented on What lurks in the dark corners of the Castle</title><description>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.
</description><link>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment2</link><guid>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment2</guid><pubDate>Tue, 08 May 2007 07:16:44 GMT</pubDate></item><item><title>Eugen Anghel commented on What lurks in the dark corners of the Castle</title><description>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.
</description><link>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment1</link><guid>http://ayende.com/2374/what-lurks-in-the-dark-corners-of-the-castle#comment1</guid><pubDate>Tue, 08 May 2007 07:14:34 GMT</pubDate></item></channel></rss>