View – ModelView – Model+Controller… In that order!

So spinning along with Results-Driven.

Where to start your application design.  I’ve always started with the database.  Then used my tools to generate the model, apply my methods to the objects.  Build out the GUI, fix the bugs, and then release.  Smooth as chocolate silk pie :)

Maybe not, you end up spending forever trying to make your customer happy with the results.   My biggest annoyance is to have to tell my customer “It can’t work that way”.  I like to be the yes-man.

Starting with the GUI or the View avoids this situation.

From there you can start working on the ModelView.  The model view is doing two things for you at this point.  Giving you mocks to test your GUI, and also defining the “grain” of the application.

Understanding the “grain” of the application is important.  Too many times starting at the database level I created schema’s that were so fine grained they were almost unusable.  Models of 3rd, 4th and maybe even 5th level normalization.  Which in turn gave me super bloated business layers, and horrendous GUI’s.

Moving down the chain, the Model+Controller come into play next.  The model should just be data, the controller should be the methods to perform actions. 

So for a ModelView you might have an object like.

   1: public class ModelView

   2: {

   3:     public int Id { get; set; }

   4:     public string Name { get; set; }

   5:     public string Email { get; set; }

   6:     public bool IsNew { get; set; }

   7:  

   8:     public void New();

   9:     public void Load(int id);

  10:     public void Save();

  11: }

Based on the above ModelView, which is already wired up to the GUI, we can surmise that our Model+Controller needs at the very minimum.

   1: public class Model

   2: {

   3:     public int Id { get; set; }

   4:     public string Name { get; set; }

   5:     public string Email { get; set; }

   6: }

   7:  

   8: public class Controller

   9: {

  10:     public Model Get{int id);

  11:     public Model Create(Model model);

  12:     public Model Update(Model model);

  13: }

All that is left is to wire up our Model+Controller, as long as the user’s feedback was taken into consideration during the View-ModelView timeline, we should have a working app that everyone is happy with.  Plus 2 layers of flexibility, database changes can be worked out in the controller or service layer.  Gui changes can be worked out in the View-ModelView, and then flowed down through the rest of the system.  All is good in the world again.

The first time I took the GUI-First approach, was a Time-Entry system.  The module for the ERP system had everything we wanted, but the time entry system sucked.  Since I already had the tables the data had to fit into, I saw it as a challenge to let the users go wild with the gui.  I tried to put in all the nifty little short-cut items to help them enter their time as fast as possible.

The application was a phenomenal success.  The users loved the gui, and I mean loved it.  I was instantly promoted to Hero status.

Code can be found in trunk/Samples/View-ModelView-Model+Controller on my codeplex site coderjoe.codeplex.com.

Proof of Concepts

So what is a Proof of Concept? A confidence builder for both you and your customer. Your customer will have the chance to see the fruits of your labor. Be able to offer feedback on what they expected vs. what you gave them. You now have real experience with the subject matter. You should be able to give relatively quick answers of "yeah we can do that", or "how about we do it this way". Also, it’s a place for us to ignore the realities of development and build something just for the sake of completing a task quickly. A place for us to learn the bounds of the technology. There are no rules in the Proof of Concept. Most important, its completely throwaway. Don't bother even checking this piece of crap into source control. I'm serious don't do it. Your next attempt at implementation will be 10 times better than anything you can steal from the proof. If we intended to keep the code, it would have been called a "Draft". Next time Solution Organization

Getting started.

Now, where to start... We need to figure out what the user wants in as little explanation as possible. The more you talk to the user the more chance they have to get a vision. Once they get that vision, it will be your responsibility to achieve it. If they start asking specifics or what you think, let them know you just want to get a “feel” for what they want. They can add details once you get the baseline in place. We don’t need/want to know every fringe case and how to handle it. Nobody knows the real business rules anyways. I don’t know how many times I’ve had an expert tell me it “HAS to work this way!”, then during the last week of testing (crazy scenarios are ignored until then), the final user tells the expert that rule was dropped years ago. Same thing with technology targets. I take our build server as an example. We purchased Team Foundation Server, plus Architect licenses for every developer we have. As a skunk works project I setup CruiseControl.Net to build and deploy our dev environment. My counterpart setup TFS, and the whole build process in there. Ran across 2 minor details that he didn’t feel like working out, that CC.NET could handle easily. And here we sit, with our SVN+CC.NET dev environment. If you build it, and it works, nobody will care about the details. So, you have survived the initial requirements gathering. Hopefully with no more than a little sketch of the interface you need to build. And pages of scribble to make it look like you were paying attention. Next time Proof of Concept.

Its all about the results.

Results... Forget about Agile, Waterfall, [ insert latest trendy methodology ]. In the end its all about results. My question, what is the "result"? Is it just the part that your customer wants. Is it the scalability of the architecture. How about enabling graceful change. Now that your app is prod the users hate it and want it to work the way you tried to tell them it should. Or maybe its high maintainability. Maybe you just don't know yet... My plan over the next few posts is to go over my methodogy for achieving the *best* result as fast as possible.