How do I configure an ASP.NET MVC project to work with Boo - asp.net

I want to build an ASP.NET MVC application with Boo instead of C#. If you know the steps to configure this type of project setup, I'd be interested to know what I need to do.
The MVC project setup is no problem. What I'm trying to figure out how to configure the pages and project to switch to use the Boo language and compiler.

So there are two levels of "work with Boo". One would be all the code (namely, the Controllers), and the other would be the views.
For the code, I assume Boo compiles to standard .NET assemblies, so simply properly following the naming conventions using by ASP.NET MVC should allow you to write Controllers. You will probably need to start with a C# or VB version of the MVC web application project template and port some of the boilerplate code over into Boo to get the solution entirely in Boo (I presume Boo supports Web Application projects?).
The other half is views. Someone will need to port the Brail view engine over to the ASP.NET MVC view engine system. This may already be done, but I don't know for sure. If it's not, then this is probably a significant amount of work to be done.
Probably the best place to get answers to these kinds of questions is the MvcContrib community on CodePlex.

The Brail view engine has been implemented to be used in ASP.NET MVC. The MvcContrib project implemented the code. The source code is located on Google Code.
As far as the controllers, I really am not sure. I am not that familiar with Boo. I know a lot of developers use it for configuration instead of using xml for instance. My tips would be, if Boo can inherit off the Controller base class and you stick to the naming conventions, you should be alright. If you vary off the naming conventions, well you would need to implement your own IControllerFactory to instantiate the boo controllers as the requests come in.
I have been following the ASP.NET MVC bits since the first CTP and through that whole time, I have not seen somebody use Boo to code with. I think you will be the first to try to accomplish this.

Related

ASP.NET MVC 3: can I combine C# Razor Views with F# Controllers?

I figure this is a straight forward question, and I think there is a good chance the answer is "yes" (while mixed-language projects are generally not possible, it seems to me that the View Engine gets special treatment). I know I could also try this out pretty easily myself, but for the record, and to save myself some time, I'd like to know if this combination is possible (I've not used ASP.NET MVC or Razor myself yet, I'm considering options for a new project at work).
Edit: I am particularly interested in whether this combination is possible within a single project. Or more specifically whether there are any feature losses using this combination (even if the two project setup is the way to go).
You can definitely mix a C# Razor code with F# controllers. It may be possible to do this in a single project (by modifying the web project to use F#). An easier alternative is to create a standard C# Razor Web project and a separate F# project (containing model and controller code).
I created a Visual Studio template that allows you to do exactly this.
Unfortunatelly, the template is not yet available on Visual Studio Gallery (so you cannot see it from "Online Templates" tab in "New Project" dialog). There is some issue with their upload mechanism, that I'm trying to resolve, so it should hopefully appear there soon. There are also several ASP.NET MVC templates by Daniel Mohl on Visual Studio Gallery, but I'm not sure if any of them uses Razor.

General setup for Nunit testing in ASP.NET webapplication

Coming from Java programming, I'm used to the general Main<->Test Maven-setup for a project.
Whenever there's a new build, all tests will be run by Maven/Junit and I get feedback about them.
I've been looking around and I can't find an analogue way for ASP.NET and Nunit.
Am I forced to put my UnitTest-classes in the APP_Code folder?
What's the general way to do this? Are there any recommendations for continuous integration?
The best way to architect a TDD-able web app is to put all your code in codebehinds; no inline ASP. Make the controls in the codebehind classes public, and develop your logical operations (bind/unbind, maybe) via TDD. As long as you can see the control and its children from outside the assembly, the unit tests can go anywhere.
Also consider an MVC setup; doesn't have to be the actual MVC framework of .NET, but if you strip down the codebehind to the absolute bare minimum, and perform all your logic in a controller class, then you can provide a mock page/codebehind for unit-testing the controller logic.

Improving testability of ASP.NET site without rewriting to MVC or WCSF

I have an ASP.NET web app which is growing.
It is done in traditional web forms. While I would like to convert it WCSF to improve testability, this is time-prohibitive. I have taken the action to only make method calls in ASPX code behind which call the appropriate methods in the classes in App_Code so the spaghetti code is gone, which is good.
What else could I do to improve testability without any fundamental rewrite?
Thanks
Is this a Web Site project? I find Web Applications are more structured and easier to maintain. I'm not sure if they are more testable. Then do use namespaces where a web site does not.
Have you considered using a UI pattern such as MVP? You also might get partial coverage with creating interfaces for your code-behinds and testing against the interface. Watch out for hidden side-effects (changing the state of a dropdown within a method, it hidden behavior).
A book I found helpful was 'Working Effectively with Legacy Code' by Michael Feathers.

Usefulness of asp.net MVC framework as opposed to coding MVC style with regular asp.net?

I am new to the asp.net world (but not new to .net) and I have been playing around with various things to see how I want to architect a web application I am developing. In my playing around I have decided I did not want to use asp.net's controls, as I have done enough php and ruby on rails to be decently familiar with regular HTML, and a decent amount of javascript.
I see a lot of comparisons between asp.net webforms and asp.net MVC, however when ti comes down to it I am not seeing that much of a difference (and I'll admit that it's probably me missing the differences rather than them not being there). I already have coded my asp.net application using a MVC type of architecture (aspx has the view, aspx.cs has the controller code, and models are separate classes in the app_code directory).
If I do not intend to use asp.net controls and just intend to use pure html and javascript, what are the advantages of using the MVC framework? As of right now, the only one that I am seeing is routing, and I'm sure if I look more I can find easy ways to do custom routing without using the whole MVC framework.
Anyways, if anyone could go into details of asp.net webforms minus the asp controls versus mvc framework, I would be greatly appreciated.
You're going to find a number of differences and reasons to use MVC over WebForms but it's going to depend on whether those differences are important to you or your project. Routing is definitely a big advantage for MVC. Although you can implement custom routing configurations in WebForms it's significantly less intuitive.
Another big advantage is unit testing. Along with an IoC container and a mocking framework, MVC makes unit testing a cinch. It's much easier to isolate actions and behaviors with MVC and test those specifically.
A third advantage is that MVC will help reduce the spaghetti code you're going to write. If you're not planning on using any User Controls then it won't be long before you're missing the HTML helpers in MVC. The Html, Url, ViewModel, TempData, etc make working with raw HTML much easier.
The inherent validation in MVC is also impressive. It's getting better in MVC2 and now with the integration with client side validation libraries it will save you a ton of time and add a lot of functionality.
No more VIEWSTATE.
There are many others but again it depends on whether those features are important to you. Good luck with your decision!
ASP.NET MVC is built on interfaces, which makes it extensible, easy to write unit tests for, and encourages clean, loosely-coupled architecture.
If you're using 'classic' ASP.Net without using any of the server-side controls, there's not much of ASP.Net that you're using -- it's basically classic ASP with .Net instead of VBScript behind it at that point.
Giving up webcontrols is the biggest reason not to use ASP.Net MVC. If you're fine giving that up, I'd just use ASP.Net MVC and be done with it. It's got all the parts you'd need to write yourself anyway, and the parts you don't like, you don't have to use.
In my playing around I have decided I
did not want to use asp.net's
controls, as I have done enough php
and ruby on rails to be decently
familiar with regular HTML
Thats not a good reason to decide against ASP.NET controlls. The importand thing about ASP.NET is Viewstate. It allows you to use event driven programming in Webapplications. This makes a lot of things very easy and productive.
Anyway - as you know ruby on rails I guess you will pick up ASP.NET MVC pretty fast.
First up, if you use ASP.NET MVC you'll be using a supported framework that has books, online resources and hundreds of blog posts surrounding it.
Second, I suspect you need to play with ASP.NET MVC to see it's power. There is way more than WebForms in ASP.NET MVC. For many, the fact that WebForms is optional (you can use different view engines) is a major plus.
For me, the extension points, the cleaner code, and the unit-testability of everything I do are major reasons to never go back to ASP.NET "classic".
My recommendation to you is to get a decent tutorial (look for the Nerd Dinner tutorial), play with ASP.NET MVC, and find out for yourself.
Note: ASP.NET MVC is not for everyone, and if you're heavily into the post-back mechanisms in ASP.NET, or have a heavy investment in server and user controls, then you might not want to take ASP.NET MVC right now. But for your next project you should at least know what your options are.

Can Standard .NET CMS systems be made to work with ASP.NET MVC

Has anyone successfully used a CMS developed for standard ASP.NET with ASP.NET MVC?
I currently use Immediacy CMS and it seems to be quite tightly coupled with standard ASP.NET, but I'd really like to start using ASP.NET MVC.
Are there any CMS systems out there directed at MVC?
How could I persuade my employer to move to ASP.NET MVC?
I suggest take a look to Kooboo (kooboo.com), a simple to use but powerful for developers. Well documented API and based upon ASP.NET MVC (of course ;-)
N2 CMS has an example site in ASP.NET MVC that I've been playing around with that works quite nicely - note that the code is now hosted on Google Code.
The problem you've got is that many CMS' already do a lot of "routing" in that the pages you are requesting/editing don't actually exist on disk, but are all in a data store of some kind, and there's an HttpHandler or ISAPI Filter sitting in front of ASP.NET to intercept the requests and work out what should be happening.
I have not personally seen any of the big name CMS systems out there upgraded yet to take advantage of many of the new things the .NET framework offers, let alone start working on the MVC framework.
As with all things, a cost-benefit analysis is the best way to convince your boss to do anything. If you can point how how moving towards the MVC framework is going to make some immediate positives (as well as many long term positives) that can outweigh the costs (in time, energy, and money) in the switchover, then you have succeeded.
ASP.NET and ASP.NET MVC are very different beasts in terms of how you develop applications on top of them. Technically, an ASP.NET MVC application is an ASP.NET application with some generic handler that invokes the core MVC framework.
The ASP.NET MVC framework is also relatively new (1.0 just released last MIX) and so it'll take a while before becoming mainstream.
How you can persuade your boss? Talk to him about the positive sides of ASP.NET MVC, and how it will improve his future business. There's plenty of material available to demonstrate that.
I do a lot of work using Immediacy (I used to work there) and I had thought about doing the same thing a couple of months ago. I think that the main issues would result from things like the plug-in handler, the idoc handler and (if your still using it) the ilink hander.
When you enable things like friendly URLS I think this would cause issues if you had similar named methods in your controller actions.
You may be able use some MVC in your project, I could see it working as an admin add-in but I couldn't see it being used to usefully in the main webroot.
I would think a CMS would have to be built using MVC in mind to get the most benefits from using the pattern, instead of trying to make it work in parallel with a pre-existing system API (limited as it is) and making more work for yourself.

Resources