Thursday, December 10, 2009

Rails Study Apps

I’m trying to pick up some rails in my spare time. Been plugging away at my pet project when I can, which leads to a lot of googling while I do it. If one of my known Rubyist friends is at a Code and Coffee session, I spend a fair amount of time picking their brains and pairing up to learn what I can in an hour or so.

That all works pretty well, but at my pace I’ll be forever getting my Ruby code to look less like C# and more like Ruby. So, as Steve blogged recently, why not find a few Rails apps to read? So, I hit up my twitter friends: http://twitter.com/timwingfield/status/6464205602

I got three pretty good responses, and finally got time tonight to pull them down and take a quick look at them. I don’t have a lot of info on any of them, but I did browse the source to get a feel for what was going on.

Radiant CMS

http://github.com/radiant/radiant

This one was recommended by Dugald Wilson. Decent amount of code here to look at, and uses RSpec for the test framework. This one definitely fit the bill for what I was after.

Spot.us

http://github.com/spot-us/spot-us

I got this one as a tag team recommendation from Scott Walker and Matt Darby. This is a non-profit company doing Community Funded Reporting and is coming from the folks at Hashrocket. More RSpec out of this project, and again a fair amount of code to pour over.

Redmine

http://github.com/edavis10/redmine

The third one came through Ben Wagaman. This one uses TestUnit instead of RSpec, but still some decent reading. I’m going to have to dig into the tests a bit more on this one, though, because the file names aren’t jumping out at me as model/controller/etc type tests. But, that’s the point of this exercise, to see what other folks are doing.

I’ve got a little flying and a lot of driving ahead of me this weekend, hopefully I get some time to dive deeper into what each of these apps is up to, and get some more Rails code under my belt.

If you’ve come across a few more open source Rails apps out there, please drop a link in the comments.

Saturday, November 14, 2009

ASP.Net MVC: A Step in the Right Direction

A link to Doug Copestake’s article “ASP.Net MVP: A Step Backwards?” was forwarded to me, and it made some short rounds on twitter. I read it and had a comment underway and thought, “This is WAY to big for a comment, let’s blog it!” So here we are.

Off the top, I’d like to give a tip of the hat to Doug for stepping outside his day to day and taking a look at ASP.Net MVC. It’s very easy to hide behind FUD and just blow off something different. Additionally, his initial findings are pretty much on par with most other folks happy with WebForms who take their first look at MVC.

The MVC framework definitely provides simplicity and separation of concerns to web development. It allows you to only write the code you need to write to get the job done, and it allows you to work with the framework. Views become very small and very specialized, controller actions mature to be very thin, and it’s all easily testable.

This has made my work with the MVC framework extremely successful. Since everything is easily testable, as we refactor the code to clean it up or add new functionality, it all flows very easily.

Control reuse comes from veteran WebForms developers quite often. But if we again point at simplicity, how many of those drag and drop controls were written to cover more functionality than you need? You drag a grid control out and use 15% of it’s power because its made for everyone. Yes, you can write your own application controls to do exactly what you want, but you can do that in MVC, too.

Another point to control reuse is the leveraging of more javascript frameworks to do many of the things that the WebForm control suites do. In jQuery UI alone, you’ll get tabs, accordion panels, sliders and other UI elements, all with out that “server side” part that is so prevalent in WebForms. The win there is in more than just lighter weight controls, you gain a much better user experience. (And who doesn’t like happy users?)

The spaghetti code point Doug makes is quite valid, though I think that’s not a factor of one framework or the other as much as it is the person writing the code. The Glen Vanderburg quote, “A bad developer will move heaven and Earth to do the wrong thing,” applies to all languages and frameworks. The person with the keyboard under their fingers is responsible for keeping their code clean, not the framework developers, but I digress.

Spaghetti code in the views is a big sign that you’ve done something wrong. Even before moving to Spark, if you see lots of server instructions in your views, it’s time to stop and think, “What can I do differently here?” Same can be said of your controllers. If you’re used to writing a 50 line page load method in WebForms, turning similar code into 50 line controller actions is a step in the wrong direction. I guess the main point here is instead of relying/hoping for the framework to do the work for you, the onus is now squarely on the shoulders of the developer to keep his or her code concise.

Doug’s last point is very true, though: if you have a lot invested in WebForms in your current situation, there’s no real reason to switch away from it. Switching for the sake of switching to anything usually isn’t a good move.

That said, you can easily run WebForms and MVC in the same web application. If you have a little something to add to the project that can stand on its own, I’d say a look at MVC is in order.

This definitely would have been too long of a comment… :)

Wednesday, October 21, 2009

ASP.Net MVC v. WebForms

This question seems to come up a lot in discussions around these two ASP.Net frameworks. Just this past weekend in Cincy at the MVC Firestarter, it came up a number of times.

So, on the way to work this morning, I was listening to Hanselminutes 184, and the question was FINALLY given an answer by Scott Hunter.

If you care about separation of concerns, testability and tight control of your markup you should go with MVC. If you’re an enterprise developer and just want to get something out there quickly then use WebForms.

That’s paraphrased, I may have gotten the MVC reasons in a different order, but that was the point made.

Scary that “Just get it done,” is the main reason to use WebForms. I’ll stick with my “slow” TDD and long term maintainability in MVC and steer clear of WebForms where DDD apparently stands for Drag, Drop, Deploy.

Monday, August 31, 2009

I forgot what the M in MVC was for

What brought me to this conclusion was my reading up on a little Rails. I finally took the dive. I’ve been avoiding Rails for a while in favor of just learning Ruby. Steve loaned me “Rails for .Net Developers,” and the research was underway in earnest.

On page 89, the light bulb went off. But not for Rails so much as for how I’m writing my ASP.Net MVC apps. Here’s the bit that got me:

• Models are the classes that represent your business domain and that are responsible for communicating with your data. In Rails, this means the tables in your database.
• Views represent your presentation layer, for example, HTML and JavaScript.
• Controllers are responsible for connecting the models and views and managing the flow of the application. doing_it_wrong

That reads pretty straightforward to me. Hell, I’ve stood in front of groups of devs on more than one occasion and said, “Views are what gets rendered, controllers marry up the views with anything they need from the model, and the model is everything that’s not a view or a controller.”

So, what’s been going wrong? I’ve been putting way too much business logic in my controllers.

The structure of most of the MVC apps I’ve worked with is a typical .Net program structure. We’ve got a core where our business domain lives, and some type of ORM set up to talk to the database. From there, we expose that domain up to the UI through some simple domain services.

The issue comes when I consume those services. I’m using my controller actions to marry all that up and present it to the UI. I think my “excuse” to this point has been that I have two models: My domain model, which I’m accessing through my domain services, and my presentation model, which lives in the Models directory in the ASP.Net MVC structure. My controllers have to care about two places to get their information to provide to the views. At the least I’m violating the pattern and at worst I’m likely repeating myself somewhere and creating a future maintenance issue.

I think I can see where this happened, too. Think back to the Bad Old Days of dealing with Web Forms, and the cubby code behinds that came with it. In order to avoid the 197 line PageLoad method, I would have a lot of little one-off methods scattered about the code behind file. Switch over to MVC, and it seemed perfectly normal to have a similar structure. Alarms should have gone off when I had 5 classes in the Models directory but 18 methods in one controller class.

But wait, there’s more!

While perusing some code on my current project, I came across the [NonAction] attribute decorating a couple of controller actions. Re-reading that…I had NonAction decorating Actions. That has a certain “Jumbo-Shrimp” feel to it, doesn’t it? I suppose the non-action could fall under “managing the flow of the application” from above, but I’m thinking any non-actions might need to be refactored into the model.

Moving forward on my MVC apps – of any flavor, Ruby or .Net – I think I’ll move to a much thinner controller model in favor of loading up the model with business logic. Though I thought I knew the pattern fairly well, I didn’t practice what I preached.

Friday, July 24, 2009

Kanban At XPUserGroup – July 29

This is a bit short notice, but I just found out about it last week. (Thanks to Kevin tweeting about it. :) ) But, I’ll be presenting my “A Little Bit of Lean with Kanban” this coming Wednesday for the XPUserGroup here in Columbus. The meeting will be at OCLC at 11:30, I’ll begin my presentation at noon. (Directions and room info at OCLC.)

I didn’t plan on doing much speaking before leaving for vacation on August 1, but here’s one more session on Kanban. We really can’t spread the word enough about Kanban, so why not give one more a few days before I head south?

I’m also giving a short presentation on the 7 principles of Lean Software development next week…but you have to be an employee of Quick Solutions to see that one. (Get hired by Tuesday to see it! :) )

Friday, July 3, 2009

CodeStock Recap and Kanban Talk Slides

I had a great time at Codestock this past weekend. I didn’t get to many sessions, but I did go to a number of open space sessions (have some work to do on my blog) and the normal “hallway” sessions that never disappoint.

My talk on Lean and Kanban went really well. There were only a couple seats left in the smallish room we had, but that lead to a much more interactive discussion. The slides are available to download, with some notes in the deck.

To answer a couple more questions from the group, here are a couple of the resources I mentioned in the talk:

Coming soon will be Agile Zen. I’ve taken a peek at the beta, and it’ll be quite a tool in helping people and teams do lean development. Sign up for their mailing list to get notified when it comes out.

Tuesday, June 16, 2009

IndyNDA Recap and Covering the ModelBinder

I want to thank all that attended my MVC presentation in Indy last week. I had a great time speaking, and even though I left a portion of my code sample out (model binders, which I’ll cover below), I thought it went well and I got some good questions during and after. I apologize for leaving it out of the talk, but I get to write a little blog post about it.

A couple housekeeping things before I cover the ModelBinder part I missed.

Off the top, the slides and source code from last week are all zipped up for your downloading convenience. (The code through SVN is also available on Codeincubator.)

During the post talk talking, Dave asked me about a grid option in MVC. One we’ve been using is Flexigrid. It will do paging and sorting on its own, and will call back to your controller on its own for a little JSON. The big gotcha here is it runs on an older version of jQuery, which bit us in the butt on Friday on our project.

The blog post that contains the code and explanation…well better explanation than, “I copied and pasted and it worked,” on the partial views is on Steve Sanderson’s blog.

Now on to the part I forgot…

ModelBinder

I’m still feeling bad for not sharing this part. I got a question about it after the presentation, and that’s when I realized I totally forgot the edit page, which was going to demonstrate the ModelBinder. (Among other things, like the FluentHTML controls.)

If you have the code form above, the files in play here are InventoryController.cs and Edit.aspx. AssaultItemEditModel.cs is the object passed, but it’s just a property bag.

For the Reader’s Digest version: the ModelBinder works on the premise of convention over configuration, so the naming of your fields matter in that they have to match the property names of the object you want to bind to.

For the example I missed, we had the edit model that we wanted to bind to:

public class AssaultItemEditModel
{
    public virtual int Id { get; set; }
    public virtual string Type { get; set; }
    public virtual string Description { get; set; }
    public virtual int LoadValue { get; set; }  
}

The view had the form fields hooked to that edit model through the Fluent HTML controls from MVC Contrib.

<% Html.BeginForm("Save", "Inventory");%>
    <h2>Edit <%=Html.Encode(Model.Type) %></h2>
    <%=this.Hidden(x => x.Id) %>
    <ul class="details">
        <li><span>Type: </span><%=this.TextBox(x => x.Type) %></li>
        <li><span>Description: </span><%=this.TextBox(x => x.Description) %></li>
        <li><span>Load Value: </span><%=this.TextBox(x => x.LoadValue) %></li>
        <li><%=this.SubmitButton("Save") %></li>
    </ul>
<% Html.EndForm();%>

And finally, the controller method that’s going to process it all. Rather than taking in the standard id, it takes in a model object to which it will do all the Request.Form for you and hook the form values up to the object properties.

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Save(AssaultItemEditModel item)
{
     //do save
     var assaultItem = new AssaultItem(item.Id)
         {
             Description = item.Description, 
             Type = item.Type, 
             LoadValue = item.LoadValue
         };

     Service.SaveAssaultItem(assaultItem);

     var message = "Item saved successfully.";

     return this.RedirectToAction(x => x.Index(message));
}

Don’t mind my extra step on newing up an object with the id as a parameter, that’s due to the way I hooked up Fluent nHibernate at the start. Basically, to generate my maps from my domain objects, the id gets a private setter as convention. So, to get the right object to save, I had to set up the constructor to take an id argument. I cut some corners to get the demo app out the door. (John, you may hit me with, “Quicker does not equal better,” as soon as you read this.)

The other way around that is to not use my domain objects in my views, but that’s another discussion.

Under the hood where the magic happens, I haven’t dug too deep. But, I use this daily and it works swimmingly. You don’t even have to take in the model the view is bound to, just have the form fields match the model you’re taking in. I don’t recommend doing ad hoc model binding, in practice we set our edit model as a child of the view model.

I feel bad that I didn’t get this up on the screen, because it’s some fun stuff to show off.