is it possible to write ASP.NET (MVC) applications with F# code? If yes, how? What possible benefits would this provide?
Thanks.
Yes. In fact, we're just finishing an app using ASP.NET MVC and NHibernate, with F#.
It's pretty easy: create a C# ASP.NET MVC app, then create an F# library, and put all your controllers in the F# library. (F# doesn't have a ASP.NET project type yet.)
The benefits are the same as usual -- everything F# provides. Of particular note is how short the controller code becomes. The type inference is just excellent.
If you want to use F# record types with the MVC binder, you'll need a bit of helper code. I wrote about it here.
However, with the 1.9.6.16 release, The F# ASPNetCodeDomProvider has some bugs, making it unsuitable for use in the ASPX pages. Also, IntelliSense doesn't work there. So, for the ASPX part, we used C#. Not a big deal, as that's just usually wiring up the model to the view.
Related
I would like to know what, why or when it is better to choose cshtml and what, why or when it is better to choose aspx technologies? What are these two technologies intended for?
Thank you,
As other people have answered, .cshtml (or .vbhtml if that's your flavor) provides a handler-mapping to load the MVC engine. The .aspx extension simply loads the aspnet_isapi.dll that performs the compile and serves up web forms. The difference in the handler mapping is simply a method of allowing the two to co-exist on the same server allowing both MVC applications and WebForms applications to live under a common root.
This allows http://www.mydomain.com/MyMVCApplication to be valid and served with MVC rules along with http://www.mydomain.com/MyWebFormsApplication to be valid as a standard web form.
Edit:
As for the difference in the technologies, the MVC (Razor) templating framework is intended to return .Net pages to a more RESTful "web-based" platform of templated views separating the code logic between the model (business/data objects), the view (what the user sees) and the controllers (the connection between the two). The WebForms model (aspx) was an attempt by Microsoft to use complex javascript embedding to simulate a more stateful application similar to a WinForms application complete with events and a page lifecycle that would be capable of retaining its own state from page to page.
The choice to use one or the other is always going to be a contentious one because there are arguments for and against both systems. I for one like the simplicity in the MVC architecture (though routing is anything but simple) and the ease of the Razor syntax. I feel the WebForms architecture is just too heavy to be an effective web platform. That being said, there are a lot of instances where the WebForms framework provides a very succinct and usable model with a rich event structure that is well defined. It all boils down to the needs of the application and the preferences of those building it.
Razor is a view engine for ASP.NET MVC, and also a template engine. Razor code and ASP.NET inline code (code mixed with markup) both get compiled first and get turned into a temporary assembly before being executed. Thus, just like C# and VB.NET both compile to IL which makes them interchangable, Razor and Inline code are both interchangable.
Therefore, it's more a matter of style and interest. I'm more comfortable with razor, rather than ASP.NET inline code, that is, I prefer Razor (cshtml) pages to .aspx pages.
Imagine that you want to get a Human class, and render it. In cshtml files you write:
<div>Name is #Model.Name</div>
While in aspx files you write:
<div>Name is <%= Human.Name %></div>
As you can see, # sign of razor makes mixing code and markup much easier.
While the syntax is certainly different between Razor (.cshtml/.vbhtml) and WebForms (.aspx/.ascx), (Razor's being the more concise and modern of the two), nobody has mentioned that while both can be used as View Engines / Templating Engines, traditional ASP.NET Web Forms controls can be used on any .aspx or .ascx files, (even in cohesion with an MVC architecture).
This is relevant in situations where long standing solutions to a problem have been established and packaged into a pluggable component (e.g. a large-file uploading control) and you want to use it in an MVC site. With Razor, you can't do this. However, you can execute all of the same backend-processing that you would use with a traditional ASP.NET architecture with a Web Form view.
Furthermore, ASP.NET web forms views can have Code-Behind files, which allows embedding logic into a separate file that is compiled together with the view. While the software development community is growing to be see tightly coupled architectures and the Smart Client pattern as bad practice, it used to be the main way of doing things and is still very much possible with .aspx/.ascx files. Razor, intentionally, has no such quality.
Cshtml files are the ones used by Razor and as stated as answer for this question, their main advantage is that they can be rendered inside unit tests. The various answers to this other topic will bring a lot of other interesting points.
I have learned VB.Net with the help of some books and blogs like code project but I donot know even the basics of ASP.Net that I really want to learn.
Could you please advise me if there is any difference between the code syntax of vb.net and ASP.net or I can use the same syntax to build asp.net applications?
Thanks for your help.
If you're writing your ASP.NET server-side code in VB, then it's standard VB.NET code just like you're accustomed to. The two most popular languages for .NET are VB and C#, and you can use whichever you wish. But the fact that you're using ASP.NET doesn't change the syntax or structure of either one of them.
Basically, ASP.NET is a web framework that you'd be using to build web applications written in your language of choice (in this case, VB.NET). You'll want to know more about the framework, such as how to design your forms and make use of the web controls (and knowing HTML/CSS/JavaScript is a big help too). But the overall syntax of the VB code doesn't change.
asp.net is not a language it is a framework.
vb.net is a language which used alongside asp.net to build websites/web applications.
So in a way yes there is a difference, but the difference is that they are two different things.
It's worth noting that VS provides a somewhat watered-down interface when using VB as opposed to C#. It's really worth your time to get familiar with C#.
Microsoft's ASP.NET hub hub is a very comprehensive resource for tutorials. I'd recommend starting there, and coming back here when you have a specific question.
ASP.NET is the technology, and you can choose which language you want to use with it. C# is the most widely used Microsoft languages, but you can develop ASP.NET applications in VB.NET too.
Use VB.NET to fimiliarize yourself with ASP.NET and get a handle on how it works. Eventually, it would be a good idea to learn C#, because it's the most widely used snytax in the world. Most modern languages are rooted in the C syntax, so by learning one of them you're learning all of them. It really is the biggest bang for your buck in terms of applicable experience.
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.
I'm writing a component that I would like to be able to use in both MVC and WebForms web apps, but I'm not sure how to handle the differences between how HttpContext is handled.
My component involves a custom IHttpHandler (for WebForms) or a custom ActionResult (for MVC).
So I've got a few questions:
Is there a way to use an IHttpHandler with MVC without breaking the model?
Is it acceptable to use HttpContext.Current while attempting to write code that will work for both? It seems a little brute-force-ish to me (not sure why), but the alternative would be writing and implementing an fairly verbose interface to handle the abstraction between HttpContext and ControllerContext.
Am I going about this completely wrong?
Yes, you can just use routes.IgnoreRoute("MyHandler.ashx"). It'll fall back to the original ASP.NET handling without breaking the model.
Nope, I think it's perfectly OK to use HttpContext.Current. I think when you are writing your own handler, MVC is not very applicable. You are writing your code for ASP.NET, not ASP.NET MVC or ASP.NET Web Forms. It's easy to make it working on both models (works OOTB with Web forms, with IgnoreRoute in MVC). You might making thing more complicated than they should be! Remember, the sole purpose of design patterns (such as MVC) is simplicity. Don't make things complicated!
goto 2; Just write a simple handler!
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.