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.