I am a rails developer and I am looking for a good .Net MVC book or tutorial. I don't know where to start. Do I have to learn .Net web forms and c# first, or can I go directly through .Net MVC?
You don't necessarily have to start with Web Form; being a Rails developer, it might even be easier for you to start with ASP.NET MVC. Ultimately, each offers a very different approach to web development and your choice will depend on your specific needs. Many will argue that MVC is the better choice.. realistically, each has its place. Moreover, keep in mind that not every ASP.NET MVC web application will be built from scratch; several projects will probably end up migrating from classic ASP.NET.
C# is one of many programming languages available for use in .NET....and although I strongly suggest learning C#, you could -technically speaking- use an implementation of Ruby called 'IronRuby' to get started. Should you first learn C#? Again, it's up to you... though just as it is helpful for a Rails developer to be proficient in Ruby, being comfortable with whichever language language you choose will prove helpful in learning a new framework. More importantly, the learning curve will seem much steeper if yo try to tackle both at the same time.. C#, can certainly differ from Ruby.
Anyhow, I highly recommend PluralSight & Microsoft's Virtual Academy to get started.
As user3435091 says, you don't need to learn WebForms, that is the old school way to do web applications in ASP.NET (the book detailed below explains why, but basically it has to be with actually web apps tend to be stateless and webforms goes to the opposite direction). With ASP.NET MVC, you will find a fundamental similarity to rails, you have Models, Views and Controllers as you would expect (they both follows MVC which is an architecture), so you don't have to change the way you think today about building a web applications. The template engine MVC uses is Razor which also uses the concepts of views, partial views, layouts, helpers, helpers for ajax, etc (it uses jQuery by default too).
The hardest part to learn I think would be with ORM (you have EntityFramework and NHibernate, the .NET implementation of Java Hibernate :s ) and that C# uses attributes (similar to java annotations). Also, you are not provided with the nice rails console out of the box in .NET.
The book I used to learn ASP.NET MVC 3 (and which I can recommend) is Pro ASP.NET MVC 3 by Adam Freeman and Steven Sanderson.
Hope that helps.
Related
MVC frameworks in general?
Is it different from MVC in desktop GUI applications?
What exactly is it that makes it easier to test than WebForms ? (Can't you test Code Behind in a similar way to MVC controllers)
I have the impression that ASP.NET MVC is mostly about clean URL's - with controllers processing user input in the form of URLs.
A barbone web forms application in classic ASP for example is very different from the MVC concept. While ASP.NET Webforms with events and page-state goes more in an MVC direction as one thinks of it in a desktop GUI world.
How about trying Wikipedia?
Quoting: "Model–View–Controller (MVC) is a software architecture, currently considered an architectural pattern used in software engineering. The pattern isolates "domain logic" (the application logic for the user) from the user interface (input and presentation), permitting independent development, testing and maintenance of each (separation of concerns)".
So it helps making an application organized (because it imposes that you separate your business or domain logic [model] from all interface code [view]).
It also makes much easier to apply TDD.
And, speaking of Web MVC .NET frameworks (like ASP.NET MVC, Castle Monorail or OpenRASTA), they also normally allow:
Seeing web pages as they really are - stateless resources (instead of creating fake state retention, like the ASP.NET WebForms ViewState).
The existence of client-side programmers in your job that do not know (and probably don't want to know) anything about .NET.
Elegance (as opposed to spaghetti code, or, well, WebForms).
Nice URLs!!!
BTW: there are a LOT more benefits, and if you are unable to perceive them, I would recommend that you look beyond the .NET world. You'll notice that almost every other language/environment has at least one MVC framework available:
Python has Django.
Ruby has Ruby-On-Rails.
Java has Spring, Play.
PHP has CakePHP, Symfony.
And so forth...
Which clearly shows that MVC is an idea worth repeating, and a proven architectural pattern.
Today, I came a cross a blog post for David Hayden explaining why he thinks ASP.NET MVC developers should learn Ruby on Rails.
Some of the reasons David mentioned:
ASP.NET MVC was inspired by Rails and in order for me to be a smarter ASP.NET MVC Developer I feel like I need to know Rails.
IronRuby is well on its way to being released which has got me excited about learning a new language, Ruby.
I really, really like Cucumber and RSpec and would love to use them for BDD via IronRuby on my ASP.NET MVC C# Projects.
I think it would be cool to develop ASP.NET MVC Web Application using Ruby via IronRuby.
What do you think guys? Is it really important for ASP.NET MVC developers to learn Ruby on Rails? If we are evaluating this option on a scale of 5 degrees ( Urgent-Important, Urgent-Not Important, Not Urgent-Important, Not Urgent-Not Important, A Total Waste of Time), what would your choice be guys, hopefully you will mention some benefits resulting from your experience working with both. Some articles, blog-posts on that subject are totally appreciated.
PS: There's a real use-case for this stuff, as my team leader is offering some courses on the house, and I was really considering Ruby on Rails.
I would disagree that ASP.NET was inspired by RoR.
Not Urgent-Not Important
That said I have used RoR and its great, but it will not help you become a better ASP.NET MVC programmer any more than learning other technology or tools.
It is always good to learn something new to broaden your abilities.
So my answer is yes learn Ruby on rails because you will be a better programmer for it, just not a better ASP.NET MVC programmer :)
not urgent, not important. It's never going to be a bad idea to learn RoR as it will give you a different perspective, but I think it's more important to get a deep knowledge of ASP.NET MVC and understand the full implications of using the MVC framework on top of the ASP.NET stack. Things like session and cache management as well as routing and controller actions work differently in ASP.NET MVC to RoR not to mention you're using MVC within a statically typed environment rather than the dynamic language of ruby so I think your focus should be on going deeper with ASP.NET MVC that trying to glean what you can from RoR just for the sake of it.
I would say it "Not Urgent-Important". Many features are of ASP.NET MVC is inspired by ROR. Apart from this, learning Ruby itself will be a great learning experience. It has many language features which you will find in .NET 4.0. So, it helps you to stay on curve with respect to where programming languages are heading.
Besides there are many cool things Rails provides. Understanding it opens up doors of opportunity when you work with asp.net mvc.
Apart from this ruby language already has RSpec for BDD. Learning this will broaden your understanding about BDD and will be helpful when you plan doing BDD with asp.net mvc.
Overall you will learn many good programming practices as well. So, the journey would be interesting..
Give it a shot, hope you won't regret it, as there is nothing to lose.
I work for a small website company (couple of programmers, couple of designers). Currently we use ASP.NET website projects - this makes it easy for me to sort the programming out on my local machine, while the designers work directly on a development server and the 'on-the-fly' compilation allows them to see any changes made without having to compile and deploy the website (and all tied up with SVN).
I'd like to start using ASP.NET MVC for pretty much all the reasons that makes it different from Webforms (logical urls, no viewstate, more control over html, unit testing etc..) but don't want to make the dev process over complicated, so:
Any reasons you can't set MVC websites up as website projects instead of Apps so they don't have to be explicitly compiled throughout the dev process? (Our 'live' websites all use web compilation projects anyway).
Will this still allow unit testing?
Is there any other way of allowing the designers to develop MVC sites in the same way as they currently do? Note: They use Dreamweaver, so no Cassini development server.
Can anyone advise with any of the above (even if only to tell me my dev process makes no sense.. :)
Thanks.
ASP.NET MVC is a great platform no matter what type of project. If you already understand the basics of HTTP and how websites actually work ASP.NET MVC will be like the thing missing from your life. If you're used to the postback model of ASP.NET WebForms it may be a little harder to grasp at first but it's very easy to understate. It's basically a stateless model. Your controller is given some parameters, it writes back some HTML... end of story until the next request.
I don't think so, and I think the reason for this was to allow bin-deployable ASP.NET MVC projects. You can publish an ASP.NET MVC app straight from Visual Studio 2008 without the end server ever even having to know about ASP.NET MVC, as long as it has ASP.NET 3.5 (with SP1 I think)
ASP.NET MVC is all about unit testing, it's extremely flexible in this matter and even some of the design decisions behind ASP.NET MVC are based off allowing users to unit test their code. Scott Guthrie specifically names unit testing in the latest release of ASP.NET MVC (beta) http://weblogs.asp.net/scottgu/archive/2008/10/16/asp-net-mvc-beta-released.aspx#six
Any controls that work with ASP.NET WebForms will work with ASP.NET MVC as long as it does not rely on postback. If it does than you cannot use that control/code.
MVC is a proven design pattern for websites and even the very one you posted your question on is based on ASP.NET MVC and was built by only a few people and is now maintained by 1 (one) person (soon to be 2). I currently am using it for 3 private projects and I love it. I've seen the light and I will never go back to WebForms.
Resources:
Scott Guthrie's blog
Phil Haack's blog
Rob Conery's blog He has created an MVC Storefront demo over 25+ videos.
Scott Hanselman's blog
Stephen Walther's blog
PDC08 ASP.NET MVC Session Session was with Phil Haack and Jeff Atwood (creator of this site).
HTH!
I used to be an ASP.NET developer. Recently I started developing with Django and do so with one other developer remotely via SVN. I find that MVC frameworks make small projects even easier, and larger projects a lot less painful than oldschool ASP.NET did.
Templates are far easier to control and style than the web controls in ASP.NET. Separation of logic (beyond the code-behind methodology) makes it easier for more than one person to be working on different parts of the site at the same time. RESTful design centered around actions starts making a lot more sense after having to deal with ASP.NET page life cycle issues long enough. Also, the URL-driven routing and the ability to do reverse lookups means fewer hard coded links in your code, its easier to add new sections to your site, etc.
To answer some of your questions:
I'm not sure about live compilation, but its easy enough to write some simple deployment tools to automate this process.
Unit testing is often easier on an MVC framework thanks to actions in controllers compartmentalizing the logic much better.
ASP.NET MVC allows you to use webforms as the default template language, but I'd advise looking into cleaner templating languages such as NVelocity. Any HTML-centric templating system is going to be better than webforms because of how difficult it is to tame and style even simple aspects of web controls.
This site uses MVC. I think the team behind StackOverflow qualifies as a small shop. They have a lot of experience though. Still, considering how many people are involved (a few) and the number of servers, yeah, it's small. And it runs very well in my opinion.
I've noticed a lot of talk about asp.net MVC lately, but I haven't come across a clear or compelling description of when, where or why I would want to use it over WebForms.
Let's say I wanted to build a small web application that allows a person to advertise some items online. The website will have 4 use cases:
Search adverts
View listings
View item
Place an advert
Let's assume:
I'm not particularly interested in unit testing my controller. The page will either render the list of items correctly, or it won't.
I am interested in more control over the HTML markup.
I'm not interested in using the latest buzz technology just for the sake of it.
I am interested in using the tool that is best suited to the job in terms of productivity, performance, maintainability & simplicity of the end solution.
I don't want to have to work around a bunch of nuances to get something simple to work.
So, my questions are thus:
What are the fundamental differences between the two models?
In which scenario is one better than the other?
What are the gotchas with asp.net MVC (I'm aware of the gotchas with WebForms)
For our sample app, what would I gain by using asp.net MVC instead of WebForms?
For our sample app, what would I lose by using asp.net MVC instead of WebForms?
Is it feasible to mix and match models within the same small application?
Thanks to anyone who spends the time to contribute an answer.
What are the fundamental differences between the two models?
WebForms try to mimic WinForms development by allowing you to reuse lots of pre-made controls, and by faking web application state via the hidden _VIEWSTATE mechanism.
MVC is a pattern designed to help you separate your data (Model), business logic (Controller) and presentation (View). It adheres more to the true nature of the web : RESTful URLs, stateless.
In which scenario is one better than the other?
In my opinion, for an intranet application making heavy usage of controls, WebForms can be useful at reducing development time, because thanks to the designer you can create your UI very quickly and let the framework manage the app's state automatically.
For any other project, especially a public website, even a small one, I think MVC is the way to go.
What are the gotchas with asp.net MVC (I'm aware of the gotchas with
WebForms)
I'd say there is some learning curve to fully understand the MVC pattern and its power. Also, since the framework is still in BETA you can expect the API to experience some minor changes before release.
Since JavaScript is not hidden from you in MVC, it would also require some time to learn if you're not familiar with it. jQuery greatly simplifies this though.
For our sample app, what would I gain by using asp.net MVC instead of
WebForms?
You'd gain better control over HTML markup and Javascript behavior, a cleaner separation of concerns and some easily testable codebase (even if you don't seem interested in unit testing it).
For our sample app, what would I lose by using asp.net MVC instead of
WebForms?
You'd lose the 'drag and drop' quick way of building your pages and the application state management.
Is it feasible to mix and match models within the same small
application?
In some ways, yes it seems.
I'd recommend watching this talk by Phil Haack, who gives a good overview of the framework and invites Jeff Atwood to talk about how he built StackOverflow with it.
He explains how SO is using some WebForms controls for CAPTCHAs which render themselves into the view.
The primary difference is that MVC is more like "regular" web development that the rest of the programming world uses, whereas standard ASP.NET was designed to make it brain-dead easy for Windows developers to become web developers. I learned web programming by learning Ruby on Rails, and MVC seems like it is becoming the .NET version of Rails.
MVC is much more oriented around standards compliance, unobtrusive javascript, and separation of concerns than regular ASP.NET. You'll need to understand how HTML and CSS work together. You'll learn a LOT more javascript as you master MVC. One of the biggest advantages of MVC to me is that you can use jQuery to do some amazing AJAX stuff easier and BETTER than you can in regular ASP.NET.
If you're just now learning web development then I strongly encourage you to learn MVC. You'll be able to transfer at least some of your new skills to other frameworks in the future.
If you're looking for which to learn to quickly get a web development job, then I'll have to strongly suggest ASP.NET.
Once MVC is RTM'd I think we will see a slow and steady adoption curve and as it matures MVC may become the primary framework for creating websites with ASP.NET. I hope so at least!
The biggest difference between ASPNET MVC and is WebForms is the lifecycle of an page, no difficult(unnecessary) postbacks, clean coding, enz.
There are no rules for that
???
REST-full website, Separation of logic
Design-time support, can't use third-party webcontrols
Please don't mix it together. If you really want to use the WebForms model you could use the MVP pattern, Billy McCafferty wrote exellent articles on that design pattern
I'm redesigning some of my applications from the MVP-pattern to MVC-pattern, not because MVC is better but I would like to use the newest techniques offered by MS(pattern itself is quite old).
I have seen the ASP.NET community buzzing about MVC. I know the basics of its origin, and that there are many sites (unless I am mistaken, stack overflow itself) based on ASP.NET MVC.
From everything I have heard and read about MVC it seems to be the future of ASP.NET development. But since I don't usually dabble in .NET web development I am left wondering the following: when is it appropriate to use MVC and when is it not, and why? Examples of great (and terrible) use of MVC would be fascinating.
Though I realize there are other implementations of MVC view other languages like RoR I am more interested on its impact for .NET programmers.
If this has already been gone over, my apologies!
Here are my 2 cents about MVC for web applications. For the sort of GUI apps for which MVC was originally intended, "listener" code was required, so that the UI could be updated when events altered the model data.
In MVC for the web this is unnecessary, you get your listener for free: the web server, and the HTTP request IS the event. So really MVC for the web should be even simpler. Indeed, it could be boiled down to the Mediator pattern, where the Controller mediates between the model and the view.
There are two things that there is a lot of confusion about. Regardless of conventional "wisdom":
Frameworks != MVC
Database Data != "Model"
"Full stack" web development frameworks typically add lots of features, and may or may not be MVC-oriented at their core. One of the features many frameworks add is database access or object relational mapping functionality, and because frameworks and MVC get confused, subsequently database data and the model facet of MVC also get confused. The model can generally be viewed as the underlying data for the application, but it does NOT have to come from a database. A good example might be a wiki, where the underlying model/data consists of file revision data, for instance, from RCS.
Hope this helps and I'm sure others will have plenty to add.
I would say one very compelling scenario to use MVC is if you have a group of experienced .NET developers who dont have experience with WebForms.
Coming from that situation myself (very little web experience) I found it I was much more productive and comfortable using MVC over WebForms.
I found it very hard to pickup WebForms due to the aforementioned abstraction - (I think proof of WebForms complexity is I have never met anyone who I would consider a WebForms "guru" i.e. knows the Page Lifecycle off by heart/Data Binding back-to-front etc.).
Using MVC actually allowed me to use my .NET and software experience without needing to heavily invest in learning the WebForms framework. Not only that but I got a much better understanding of HTTP, and this I think would allow higher quality solutions.
IMHO MVC allows you to factor code much better than WebForms, so I think developers with lots of "patterns" experience will be more comfortable in MVC.
ASP.NET MVC isn't the future of ASP.NET development it is just a new way of developing websites with ASP.NET. Microsoft have made it clear they will continue supporting and improving both WebForms and MVC in the future.
I cannot think of any websites, were it would not be appropriate to use MVC. You could also argue the same for WebForms.
Whether you choose one over the other is a personal choice, and would depend on the development team's experience and preferences.
I personally would never go back to WebForms development after using MVC on several big projects. WebForms in my opinion places an unnecessary abstraction layer over http and html. For quick prototypes you can get something cobbled together quicker with WebForms, but after that the complication of the abstraction makes things harder rather than easier. The only compelling reason to use WebForms in my opinion is the rich level of 3rd party controls that are currently available. But you can mix WebForms and MVC, so its easy enough to get the best of both worlds.
I work in a shop that has both ASP.NET and MVC applications. I think originally I was biased toward web forms because I worked with them from several years, but after working on a few MVC projects I prefer it.
Something to consider, however, is that if you have a team of experienced web form developers initial progress in an MVC application will be a slower because of the learning curve, so if the timeline for a project is very tight it might not be the best time to transition.
Aside from that I can't think of any situations where I'd prefer web forms over MVC at this point.
Based on my own experience, I can tell you that if you don't have any Winforms or Webforms background, you may feel more comfortable under the MVC umbrella because you are not "expecting" anything from the ASP.NET Webforms world.
On the other side, as a recommendation, I encourage you to check out other MVC frameworks like Django or RoR that are more mature to "be water" on the MVC way of thinking. I'm happy with ASP.NET MVC but looking other solutions helps you to understand better the paradigm behind the framework.