Pitching Castle
time to read 2 min | 354 words

As I mentioned, there is not a very interesting discussion on the Castle Developer mailing list.

One of the topics that just came up is evangelizing Castle to the community. I think that the main problem of Castle is that it help solves the problems that you have after you finished 30% of the project. That is when you start discoverring the limits of the stuff that MS is preaching. It takes prior experiance with this pain to make the trade off visible. I know that in the past I have talked about the seperation of UI / business logic that is inherent to MonoRail, and I got responses like: "Well, that is why we have code-behind files in ASP.Net".

I wasn't sure quite how to deal with that argument then. Every now and then I see people who are fortunate enough to build applications where the UI is truly just the ASPX and maybe a single line or two of databinding in the code behind. But my experiance is that I often need to do complex stuff in the UI. For instnace, show certain rows in a grid with a certain color, Ajax, etc. All of which are intimately tied to the UI, and are not possible to do in the ASPX. This means that they go to the code behind file, and there goes the Seperation of Concerns out the window. I have seen a date picker control that is over 2,500 lines of code. And even in this simple control, there was some business logic involved (mostly around what valid dates are, and how to handle ranges of them.

Anyway, this discussion coincides with a request from a friend to send some information about how to sell Active Record to their team lead / architects. I uploaded the presentation to my Presentations page, so feel free to start pitching Active Record (which is the easiest thing to get into a project, I have found) and then expand your Castle use later on.

 

Tweet Share Share 0 comments
Tags: