Posts Tagged mvc
A couple of months back I mentioned that I’d be taking a break from speaking and would start focusing on learning. And that’s what I’ve been doing over the last couple of months.
For the record: in the last 8 years or so, I’ve done very little web development; and that little worked involved mostly working on middle tier components. I’ve done some work on WebForms, but not a lot. Before that, I had spent a couple of years doing “classic” ASP, with COM components providing all the middle tier and html generation.
With that said, I knew that catching up with web development wasn’t going to be easy.
At first, I started looking into ASP.NET MVC. Over the last three years I have read articles on it, I’ve seen presentations, videos, etc. I remember seeing it being unveiled at the ALT.NET Open Spaces conference in Austin, and thinking how that looked a LOT better than WebForms. I thought I’d be better off starting on that track, as at least I’d be working on a familiar environment (C#, Visual Studio, having “some” understanding of ASP.NET and MVC).
I decided to base my studies off the Test-Drive ASP.NET MVC book. I had heard good comments about this book, and I liked the approach of development the sample app from a TDD standpoint, as well as using NHibernate and some other solid Open Source frameworks. I did go through almost half of the book following along with the examples (I am planning on finishing it at some point, at least for completeness sake).
Eventually, due to peer pressure, I decided to start learning Ruby on Rails. And I have no regrets at all (can’t ever say that phrase without thinking of William Hung)!
Seriously, here’s a tag cloud of things I’m having to either learn from scratch, or relearn (after so many years of not using it):
I have been seeing quite a few people whose opinion I value jumping ship from .NET to Rails and saying many good things about it, so I figured I should check it out. Like I said, I’m enjoying what I’ve seen so far, so you can expect more blog posts with my findings in this area as time goes by.
Another Thursday, another fun Virtual Brown Bag. JB shared some more Rails/Heroku love today, and how he’s implemented the registration/login feature of http://www.virtualbrownbag.com. The more I hear and see things about Rails/Heroku, the more I like it. I need to find me some time to start messing with those things.
We had a special request from Mark, one of our frequent VBBers: he wanted to see a little example of MVVM, and maybe have a little talk on MVC.
I showed a very simplistic sample of a WPF app, where we started with having most of the code in a code-behind for a window, and then moving the code out into a ViewModel. We’ve covered the core differences between MVC (Model-View-Controller), MVP (Model-View-Presenter), and MVVM (Model-View-ViewModel, or also known as Presentation Model). The idea bein g that they’re all “presentation patterns”, aimed to better structure the code that sits closer to the User Interface.
So why so many different patterns just for that? Well, each one has a slight different structure to cater for the scenario have at hand. In MVP, the Presenter takes care of providing behavior to the View. The View does nothing more than delegating things to the Presenter. This allows the Presenter to be reused independently of the View, and it’s also testable.
In MVVM, the ViewModel gives shape to the data coming from the Model, tailoring it to the View needs. For instance, the Model may have separate properties for Address, City, State, whereas the View calls for just a single property representing the Full Address; the ViewModel will handle just massaging of the data. ViewModels fit in nicely with WPF/Silverlight due to their data binding features.
In MVC, the Controller is usually the one responsible for executing behavior, and in web applications the Controller is usually the point of entry for the user to execute operations: when the user either enters a URL in the browser directly, or clicks something on the page that sends a request to the server, there’s a Controller intercepts the call and takes the appropriate action.
ViewModels are commonly used in MVC applications as well, but different than in WPF/Silverlight applications, they only provide the “data reshaping” aspect of it.
Even on a MVVM WPF/Silverlight application you may find “Controllers”, usually helping out with the way the application flows through menus and screens.
MVP is usually the best bet for WinForms and WebForms applications. So why not use MVVM in a WinForms application? Because MVVM leverages the WPF/Silverlight data binding capabilities, which in WinForms aren’t that great.
As with all design patterns, there isn’t one presentation pattern that’s the silver bullet to all applications. Depending on context, requirements, etc., a single application may mix and match these patterns: have a Login screen implemented using MVP, whereas an order placement screen may be implemented using MVVP, whereas a more complex composite screen may be using MVVM with a Controller added to handle the flow between the different parts of the screen.
This post isn’t supposed to be nothing more than a brain dump as to what we’ve discussed at the Virtual Brown Bag this week. Please make sure to take the time and go do some research and experimentation on your own.