RubyOnRails-esque ASP.NET

I've been playing with Ruby on Rails, and there's a lot to like.

There are some things that we won't be able to get while working in C#, but we could build some stuff to get closer. I know there are some people working on porting RoR to .NET but I prefer an approach that instead of porting it, it tries to take advantage of ASP.NET even if the framework is not the same.

I think the ASP.NET compilation model (which actually compiles everything in runtime), Build Providers, DLinQ and C# 3.0 are a good start, but we need more.

We need much better support for generics in the framework. The generics implementation is good but ASP.NET does not work well with them. For example, we need to be able to define asp.net controls that use generic types and use them in the .aspx pages.

I was thinking on implementing RoR scaffolding. It can be done, and as you can use ASP.NET controls you have a lot of power there (i.e, I can turn on paging by setting a property, use skins/themes, master pages, etc). The problem is that I need to generate the Page code itself, and that is not easy and it's not easy to extend/maintain.

What I want to have is a build provider that generates an ASPX page. I'm not sure if it can be built today, as the build provider needs to generate a CodeDom. ASPX pages have a build provider. I need to chain the build providers. If I can do that, the it will be much easier to implement scaffolding and also it will be very easy to generate the scaffolding static code so you can later customize it. I'm just thinking that it might be possible... I'll give it a try ;).

 

 

10 Comments

  • I think the brail part of the monorail project is nice.



    But the rest lacks a lot of rails elegance.

  • That would be because .NET lacks a lot of Ruby elegance. We have to face the fact that .NET will not be as bendy as a scripting language. It's not were it's core strengths lie, nor where they are likely to lie in the future.



    It would be better if we looked at where .NET could achieve elegance as MS is doing with functional programming. These are the areas where .NET can make gains.



    Monorail is about as good as it's going to get on the .NET platform. I don't like the absence of a view pipeline, but apart from that it's not bad.

  • The nice thing about the brail part is that it's based on Boo which is a very dynamic language :) But still is a .Net language.









  • The castleproject.org code is a waste of time for most developers.



    On one hand, it has an incredibly clean, well factored and elegant implementation. A real pleasure to read. I especially like the microkernel.



    On the other hand, it is so far removed from 'real world' considerations that I would strongly recommend against attempting to use it for any enterprise-strength production systems. For example, the decision not to leverage ASP.NET and instead invest in an open-source templating engine (which, of course, isn't widely known, used or supported by any tools) dooms this effort to remain in the realm of academia.



  • Yes, it looks that castleproject has a serious NIH syndrome.



    My goal was to build something that took advantage of the framework and it was easy to build.



    The DLinQ build provider is 20 lines of code, most of them stealed from sqlmetal.exe



    About the power of ActiveRecord, I did not do deep research but it looks that DLinQ won't be significantly worse...







  • Hmm.. let's understand this: " Yes, it looks that castleproject has a serious NIH syndrome"



    Why? Because we use NVelocity for view engines? Because we use NHibernate to O/R? Because we provide facilities that integrate with several open source projects?



    Show me exactly where's the NIH on Castle.

  • "On the other hand, it is so far removed from 'real world' considerations that I would strongly recommend against attempting to use it for any enterprise-strength production systems. For example, the decision not to leverage ASP.NET and instead invest in an open-source templating engine (which, of course, isn't widely known, used or supported by any tools) dooms this effort to remain in the realm of academia"



    So how many brain cells do you need to use NVelocity? #if #end #foreach. That's it. How much support from a tool you need to use that? That's the real MS developers dillema...



    We dont provide more integration with WebForms because we cant. Webforms get in the way of the request flow, and the very closed MS API keep our hands tied.



    Last but not least, it's being embraced by several software shops, specially in the US. It's far from an academic exercise.

  • >Why? Because we use NVelocity for view

    >engines? Because we use NHibernate to O/R?



    OK, fair enough, but I feel that any successful framework for ASP.NET must build on top of what MS offers. If you can't, that's OK, but perhaps someone can find a different approach that supports it.



    MS is going to invest heavily on ASP.NET controls (Atlas, etc), and I want to be able to leverage that.



  • I've been a full-time ASP.NET developer for five years (since the betas) and have YET to use postback, viewstate, visual form designers, etc.



    I'm totally sold on .NET and make extensive use of the overall framework, but just because you buy into the ASP.NET platform doesn't mean you have to drink the entire gallon of Kool-Aid.



    The webforms abstraction is one of the leakiest I've seen in a long time, and it's only really useful for people who have a strong background in rich client development who can't wrap their heads around the HTTP request/response model.

  • Richard,



    IMHO ASP.NET controls are what makes ASP.NET unique and significantly different than any other web platform.



    If you need to build a complex web UI (i.e, a sharepoint like one with webparts/personalization), you will probably build a very elegant and efficient solution, but it will take you a lot of time. People who build it using asp.net controls will build it quickly. It's a matter of what you feel is better.



Comments have been disabled for this content.