I need advice.
We have a MVC2 aspx project that we would want to (nice to do, not need to do) upgrade so that we can use the Razor view engine instead of the aspx/webforms engine.
In total there is about 200aspx files that would need to be converted.
What`s your opinion of how much time it would take? And is it worth doing it?
If you do this manually, it takes long time to do this. But you can use MVC 3 Project Upgrade Tool - this will be a good choice
Telerik has conversion tool. It works quite well on simple cases, just does not help with converting master pages to layouts. I've used it to convert my project (several hundred views, up to ten master pages) - it took some time to figure out how to map master pages to layouts, but overall went quite well.
Is it worth it?
Well, it depends, mostly on how much is your project covered with tests. Razor syntax is much cleaner, I like layouts better than master pages. I always think, that migrating to new version has one serious advantage - it is a reason to review all your code, refactor things and so on, another serious advantage is to work with current technologies.
Related
As a brief intro, I spent the last few days writing my own template parser/compiler. It's been an interesting project (which I plan to continue) but it sparked some curiosity about how ASP.Net (ASPX, MVC 2/3, or otherwise) handles templates and whether it's modular enough to use in different projects. There also doesn't seem to be much discussion on the topic, so why not ask?
ASP.Net has a lot of nice features:
It's a proven system that works well in production
Templates are compiled to MSIL
It recognizes that files change and recompiles
Great debugging support
Extensible templates
So here's a question: is it possible to take the template parsing/compiling/debugging system and reuse it for an entirely different purpose? Is it modular, or is it kind of that's-all-that-asp.net-is and you either get it or you don't?
ASPX WebForms pages are not quite flexible enough for general use.
It's possible, but it's a lot of headache. (I've done it)
The new Razor engine is extremely flexible; look at the RazorEngine project for general purpose use.
However, some of the features you're describing (file change monitoring) are part of ASP.Net itself, not Razor, and will only work in an ASP.Net AppDomain.
I've been using Django recently and I really love its built-in admin interface. I was wondering if there were any C# MVC projects our there which mimicked the django admin in terms of its ease and structure?
(I'm not looking for to use the whole django model in MVC, just looking for the admin portion of it)
With enough time and customizing of the EditorTemplates & DisplayTemplates I could create something similar on a per-site basis using Html.DisplayForModel() and Html.EditorForModel() but not all of it would be re-usable, nor have I gotten around to doing something like that (though I may go that route) and it takes a lot longer to setup. My experience with Django admin.py is that 10-15 lines of code goes a long long long way.
I have previously used EntitySpaces and they offered a web-admin grid, but a) its web-forms, b) it got less and less support as they continued development with it and c) you can't really use it and LINQtoSQL at the same time, and I find L2S to require much less overhead.
Any recommendations or projects you know of out there?
Thanks!
You can create the Dynamic Data Site in Visual Studio 2010, which does the same thing like Django-admin site. It requires Entity Framework.
Check out sharp architecture, it automatically sets up admin CRUD for the entities you define. (However this is NHibernate based, so you wont be able to use Linq2Sql)
Though it would be great if the built-in editor templating was improved.
I'm done some WinForms work in C# but now moving to have to develop a web application front end in .NET (C#). I have experience developing web apps in Ruby on Rails (& a little with Java with JSP pages & struts mvc).
Should I jump straight to MVC framework? (as opposed to going ASP.net) That is from the point of view of future direction for Microsoft & as well ease in ramping up from myself.
Or if you like, given my experience to date, what would the pros/cons for me re MVC versus ASP.net?
thanks
Have look here it will help you Choosing the Right Programming Model
If you need to work really close to the wire then MVC is a great choice. By this I mean, if you need to have very tight controls over markup then; while acheivable with WebForms; it is much easier with MVC. This would be common for applications that are targeting a public (e.g. internet) audience which might have a richer graphical experience. In contrast, if you're developing an internal (e.g. intranet) business application where graphical presentation is not as critical, then WebForms has a lot of really nice enabling capabilities that will allow you to move more quickly.
Don't get me wrong, you can make WebForm applications look really really nice, but you give up some control over the markup.
Very often ViewState comes into this kind of discussion. MVC will not have any ViewState so the on-the-wire footprint will be much smaller which translates to speed and bandwidth cost savings at some point. On the downside, making stateful applications with MVC can be more painful. In contrast, WebForms will carry ViewState by default and are inherently more stateful. This is typically fine for internal applications. Keep in mind that ViewState does not have to be sent over the wire... there are extensions that allow you to offload that to a local cache. I'm not favoring one over the other, but you should be aware of what each can do in this regard.
If unit testing is important to you then MVC is also a much better choice, as this is easier as well. This is totally acheivable in WebForms but requires you pattern your code behind correctly.
Security is not a major factor since much of setting up the IPrinciple and IIdentity occure in the HTTP pipeline via HttpModules, so either will do in that regard.
Another major factor in making your choice relates to your skills relative to the time you have to deliver... If you're not used to working in a stateless manner or coding standard web technologies (e.g. html, css, jquery, etc...) MVC will take you longer to do very basic things. With that said, once in place it will likely be cleaner, smaller, more testable, and faster. If you need to move very quickly there is a lot you can do faster in WebForms. WebForms also does a lot of heavy lifting with respect to markup so there are a number of details you can leave to ASP.NET.
I actually use both for a variety of reasons, and MS has stated they plan to continue support and development for both.
MVC is part of ASP.NET. You must mean MVC vs Webform to which the answer would be: coming from a Winform background, you will find webform easier to use. For the future, go MVC.
I used to work on desktop applications too, and never really got into web stuff. I didnt even (gasp!) knew HTML (yeah, that was my programmers shame). In my new job we were going to start a new application using ASP.NET MVC and I gotta tell you, I love it. HOWEVER I think you should only go with MVC if you are or you count with someone with good html/css design skills.
Html is easy I know (I've learned it know!) but I think its kind of hard to make nice designs with html and css, specially if you suck at designing and you could probably do prettier stuff using webforms, which is a little bit easier/similar to winforms.
Also, if you go the MVC way make sure you have enough time to learn it, since you are going to go a little bit more low level, gonna have to learn more of the little details, like the actual difference between post/get and all that stuff that is pretty much completely hidden in webforms. I would really recommend getting a book, I used this one Pro Asp.net MVC and really liked it.
Finally, if your page is gonna have interactive bits, or ajax-y things, if you go the MVC way you are more likely gonna have to learn javascript/jQuery too. If you go the webforms you can use the included drag'n drop ajax controls.
Coming from Ruby on Rails or other MVC based frameworks ASP.NET MVC is almost the best choice. (ASP.NET MVC is actually only the "VC" part, so you have to add an ORM of your choice. EF and Linq to Sql is the Microsoft way, NHibernate or other ORM's are the other way. One good quick start project is S#arp Architecture which uses NHibernate as the "M" part, or you can check out WHCM, which is a project built on S#arp Architecture and other good frameworks (it is considered an ASP.NET MVC best-practices demo project) ). ASP.NET MVC uses almost nothing from the WebForms package (the only exception I found is the AntiForgeryToken), so you'll loose nothing if you're unfamiliar with ASP.NET WebForms.
But as you said you have also made console applications, which ASP.NET WebForms resemble more.
If your project is new, I advise you to use ASP.NET MVC. If your project clearly separates the M-V-C part (like in S#arp Architecture, where they reside in different assemblies), creating a console application that uses the same business logic shouldn't be too hard. If your current project is to port a WinForms application to the web, then it might be easier to use WebForms.
I should get familiar with the language before using "fancy" stuff like MVC, because it's just way easier to learn when you could almost think in the language (but it's not necessary).
Horses for courses. If you're slapping together a quick app for someone, web forms is probably quicker and easier.
If you're building a long running enterprise app MVC gives you better testability a SoC.
I've some experiences on build application with Asp.Net, but now MVC frameworks become more popular. I would like to try building new multilingual web application using with Asp.Net MVC or Castle MonoRail but I don't know which one is good for me. I don't like the web form view engine, but I like routing feature in Asp.Net MVC.
Could anyone tells about pros and cons between those?
Which ViewEngine is the better as well for overriding the master template?
Speaking as an advocate of monorail, I've got to say you should probably go for ASP.NET MVC. To be honest, the simple fact that ASP.NET MVC is going to become the default architecture within three years should probably swing it. This equation was different a year ago, simply because the default architecture had serious productivity problems compared to MonoRail.
If you want to talk technical advantages and disadvantages:
ASP.NET AJAX is a mess (avoid it), but they've now got jQuery. In fact, the jQuery support is better than any other environment. Of course, you only fully get that with IDE integration with the standard view engine.
There are some aesthetic improvements (for instance, the way model information is passed around is much cleaner and more obvious than Monorail).
Also, don't dismiss the standard view engine out of hand. You don't have to throw controls at it like you did with ASP.NET, you can code it in a pretty similar manner to Brail, only using C# instead of Boo.
There are things that are just plain ugly
* the number of methods that take object for a parameter. Good luck finding the documentation on what exactly they expect.
* Microsoft's fondness for abstract classes over interfaces. They have their reasons, but I still dislike it.
Also, in many ways, MonoRail remains the more complete platform. There's no abstraction for validation or paging in ASP.NET, for instance. Also, there's not really any help for binding to a model. The helpers have very little functionality compared to their Monorail equivalents.
Overall, though, I think ASP.NET MVC is a winner.
MonoRail and ASP.NET MVC are fundamentally very similar, you should be well off using either one of them. MonoRail has existed much longer and has therefore more higher level features.
The main strength of ASP.NET MVC is it's routeing engine, to be fair MonoRail has pretty much an equivalent routing engine, and with some modification you can use the ASP.NET MVC routing engine with MonoRail as the routing engine is not really in ASP.NET MVC but in System.Web.Routing (Released in .NET 3.5 SP1). ASP.NET MVC and integration with Visual studio is also a plus, and will probably get better as we approach RTM of v1.
The MvcContrib project contains some great view engines, like Spark, NHaml and Brail. No one could be considered "Best", A personal favourite is Spark. For more on spark: http://dev.dejardin.org/documentation/syntax
The WebForms engine has intellisense which is a great advantage that to my knowledge all alternative view engines lack.
Apart from perceived popularity and support from Microsoft, ASP.NET MVC still lacks some core features that Monorail has had for a long time like controller organization (Areas), native ViewComponents and Filters that can use IoC to name the most important ones.
I have some big applications that use all of these features and I've had a hard time porting them to ASP.NET MVC.
I have worked with Monorail for some years now and while MVC looks promising and it's flexibility is awesome, I still find it akward that for every other thing I try to do, turns out it isn't there and I have to either plug a little piece of MvcContrib, another piece of SharpArchitecture, build it myself, you get the picture. Monorail is so much easier to work with (right now, that is).
I expect things will get better in the next few of months as some proposed solutions will begin to rise against others and become more mainstream. Hey, diversity of options is good but trust me, you don't want to be in Java-land 3 years ago where there were so many web frameworks that you could build your site using one for every different page!
In the meantime I will keep slowly porting my MR apps to MVC, just in case.
I think MVC wins hands down. Its feature set is very similar, but is going to be the more "popular" of the two (and thus typically more widely supported, documented and extended throughout the development community). In addition, the new ViewEngine (Razor).. and IDE improvements factor in for me, and boost the value of choosing MVC over monorail, in my opinion.
I've used pretty much all the common ViewEngines, but wound up rolling my own (created an OpenSource Project for it) utilizing the awesome StringTemplate template engine. ST is a true separation of concerns, IMO. I find myself writing better apps as a result, with MUCH less tag soup. I also threw out a quick intro and reference guide if you choose to kick the tires on the engine. I've had awesome luck on projects I've deployed thus far using it. That being said, Razor (MVC 3) looks pretty impressive.
The last time I took on a non-trivial .Net/C# application I used Castle Monorail and, on the whole, enjoyed the experience. Early-access/preview releases of .Net MVC were not yet available. Many "Microsoft shops" will now find the "official" solution more appealing. Has anyone gone from Monorail to .Net MVC.
How did you find the switch?
What are the biggest differences, presently?
I have made the switch, since you pointed out it will be the preferred way for microsoft shops. The switch was pretty trivial and as Mike pointed out it ships with the webform view engine as the default, but like Mike also said you can still take advantage of the views you wrote in brail and nvelocity with the MvcContrib project. ASP.NET MVC, doesn't tie you to a direct ViewEngine, you can use any ViewEngine you want. I don't necessarily think this is a difference.
The biggest difference I found was grouping my controllers and views. In MonoRail you could do this easily with the ControllerDetails attribute, I was able to easily get around this limitation by coding my own, but wish the functionality was built in. I did it by creating my own ViewLocator and creating a ActionFilterAttribute.
I am a monorail user, so far I still feel more comfortable on MonoRail + ActiveRecord due to the convenience built at ActiveRecord ARSmartDispatchController. However have to say MonoRail does not have a good documentation base so far (I am one of those should be blamed as the community participant who didn't help enough to write the docs)
As I saw the comments here, ASP.NET MVC use WebForm view engine. I think MonoRail has that too but was being blamed to be quite problematic, so I wonder how is the experience with ASP.NET MVC WebForm- can you use the web form components mostly the way it works as is or you have to basically abandon most of them and stick to more template style approach (like <%= or <%# ?
While I haven't made the switch yet, I have developed on both platforms and have been doing some pre-switch analysis.
It looks like the biggest difference would be the View Engines. Our Monorail stuff uses the Brail view engine while asp.net mvc comes (stock) with a webforms like view engine. There are other view engines in MvcContrib which could help in this area, though.
Also ViewComponents and view "helpers" seem to be handled quite differently the two frameworks.
Lucky I am not working for an organization use product ship from Microsoft is a needed. So I might not directly answer to your question, However in term of using MonoRail I enjoy every part of the framework although the lack of documentation but test suite are there to guide me through.
In short I do not want to invested time in learning new framework although it closely match (each had it own convention) but ASP.NET MVC still lack of some features that I already familiar with such as feature mention by Dale Ragon ControllerDetail, ActiveRecord and so on.
The ASP.NET MVC team is still making changes before v1.0, so now's a good time to provide feedback.
Also, be aware that there are more frequent releases on CodePlex, while the home page on www.asp.net still links to Preview 3.