Almost as certainly someone who has traditionally put CRUD and some business logic in stored procedures and not used an ORM tool in the past fights the suggestion to use the ORM tool.  They most likely have gotten good at writing and tweaking stored procedures and had a positive experience with this approach or they would not fight against the ORM tool.  As usual there is no right or wrong way, just different approaches that may be more appropriate for the task at hand.

Why Use An ORM Tool:

The reason I suggest that ORM tools are the right choice most of the time is because most projects I see have aggressive time lines and limited development resources.  To that end the ORM tool lets me write a lot less code to do the same amount of work.  Take the below two methods, one gets all customers using Entity Framework 4 and the other gets the list manually using a SqlConnection, SqlCommand and SqlDataReader:

/// <summary>
        /// Method using ORM To Get Customers
        /// </summary>
        /// <returns></returns>
        public List<Customer> GetAllCustomersEF()
        {
            using (NorthwindEntities nwDB = new NorthwindEntities())
            {
                return (from cus in nwDB.Customers
                        select cus).ToList();

            }
        }

        /// <summary>
        /// Method using straight SQL to get all customers
        /// </summary>
        /// <returns></returns>
        public List<Customer> GetAllCustomersSQL()
        {
            var retList = new List<Customer>();

            string cmdText = "SELECT * FROM CUSTOMERS";

            using (SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings[0].ConnectionString))
            using (SqlCommand cmd = new SqlCommand(cmdText, conn))
            {
                conn.Open();
                using (SqlDataReader dataRD = cmd.ExecuteReader())
                {
                    while(dataRD.Read())
                    {
                        retList.Add(CreateCustomerFromDataReader(dataRD));
                    }
                }

            }

            return retList;

        }

        /// <summary>
        /// Method To Create Customer From Datareader record
        /// </summary>
        /// <param name="dataRD"></param>
        /// <returns></returns>
        private static Customer CreateCustomerFromDataReader(SqlDataReader dataRD)
        {
            Customer customer = new Customer();
            customer.Address = dataRD["Address"].ToString();
            customer.City = dataRD["City"].ToString();
            customer.CustomerID = dataRD["CustomerID"].ToString();
            customer.CompanyName = dataRD["CompanyName"].ToString();
            customer.ContactName = dataRD["ContactName"].ToString();
            //.. repeat until all fields full

            return customer;
        }

As you can see above there is a lot less code required using Entity Framework 4.  The data class, Customer, is actually code genned for me.  And the projection into the object from the database is also done for me.  All I have to do is write a query using LINQ syntax.

To get the data using a SQLCommand I have write the query in SQL either inline (as is done above) or in a stored procedure.  I have to then iterate through the results and fill a Customer class of my own making, so I have to create and maintain the code for projecting the data from the database into my objects.

The above is a very simple case,  add filtering or prefetching data in the object graph and the amount of extra code I have to write in the straight sql solution grows exponentially compared to the Entity 4 solution.  Below is possible code for grabbing all customers but with their orders also.

/// <summary>
        /// Method using ORM To Get Customers
        /// </summary>
        /// <returns></returns>
        public List<Customer> GetAllCustomersWithOrdersEF()
        {
            using (NorthwindEntities nwDB = new NorthwindEntities())
            {
                return (from cus in nwDB.Customers.Include("Orders")
                        select cus).ToList();

            }
        }

        /// <summary>
        /// Method using straight SQL to get all customers
        /// </summary>
        /// <returns></returns>
        public List<Customer> GetAllCustomersWithOrdersAllDataSQL()
        {
            var retList = new List<Customer>();

            string cmdText = "SELECT * FROM CUSTOMERS"
                             + " LEFT JOIN ORDERS "
                             + " ON CUSTOMERS.CustomerID = ORDERS.CustomerID Order By Customers.CustomerID";

            using (SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings[0].ConnectionString))
            using (SqlCommand cmd = new SqlCommand(cmdText, conn))
            {
                conn.Open();
                using (SqlDataReader dataRD = cmd.ExecuteReader())
                {
                    Customer customer = null;
                    string customerID = "";
                    while(dataRD.Read())
                    {
                        if (customerID != dataRD["CustomerID"].ToString())
                        {
                            if (customer != null)
                            {
                                retList.Add(customer);
                            }
                            customer = CreateCustomerFromDataReader(dataRD);
                        }

                        customer.Orders.Add(CreateOrderFromDataReader(dataRD));
                    }
                    if (customer != null)
                    {
                        retList.Add(customer);
                    }
                }

            }

            return retList;

        }

        private Order CreateOrderFromDataReader(SqlDataReader dataRD)
        {
            Order retOrder = new Order();
            ///...fill order
            ///
            return retOrder;
        }

        /// <summary>
        /// Method To Create Customer From Datareader record
        /// </summary>
        /// <param name="dataRD"></param>
        /// <returns></returns>
        private static Customer CreateCustomerFromDataReader(SqlDataReader dataRD)
        {
            Customer customer = new Customer();
            customer.Address = dataRD["Address"].ToString();
            customer.City = dataRD["City"].ToString();
            customer.CustomerID = dataRD["CustomerID"].ToString();
            customer.CompanyName = dataRD["CompanyName"].ToString();
            customer.ContactName = dataRD["ContactName"].ToString();
            //.. repeat until all fields full

            return customer;
        }

To add the prefetch of Orders in the straight SQL solution I have to write code to project into my customer than check each row to see if the customer changes, and then add orders to the customer. This supposes I do not mind that the customer data is duplicated for each order returned for the same company. If I want to optimize data transfer things get even more complex.

Even in a fairly simple example I have a lot less code to write and maintain using the ORM solution.  When the database schema changes this means I have less code I’ll have to update to accommodate a schema change.  If the ORM is statically typed, as is Entity Framework 4 and LLBL Gen Pro, then I’ll also have the benefit of seeing where my code breaks when the schema is changed at compile time.   The less code I have to write by hand and alter when I make changes to my data model the better, and the easier these changes are to find the better.

ORM tools have not always been so friendly to data model changes.  nHibernate uses an XML mapping file, or used to.  Up until Entity Framework4 synchronizing changes to your schema into code was not that straightforward.    LLBL Gen Pro code generates its data layer so handles changes to the schema pretty well, but was hard to learn to use.  Even given these earlier drawbacks, I would still argue they allow more rapid development with limited resources available.

Also, ORM tools allow you to rely on the expertise of those who wrote them when it comes to creating the SQL that is actually run on the database.  If you have a DBA and are confident that you can tweak your own SQL effectively this isn’t an issue.  More and more, however, I run into projects where no one has a very deep SQL background.

Why Use Straight SQL:

None of this is to say that straight SQL does not have its place.  I always use stored procedures in reporting oriented applications, as their needs are heavily data processing intensive.   In circumstances where performance is the highest priority and time line and available resources are not an issue then the straight SQL solution is better suited.  If you know what you are doing you can achieve higher performance with your own code.  However, you have to know what you are doing.  Writing your own data layer does not guarantee better performance.

Conclusion:

As the title suggests I believe an ORM tool is the best choice most of the time.  Most projects have short time frames and limited resources.  Where performance is the absolute top priority or you have heavily data processing tasks in the application then a straight SQL approach may make sense.  Even in these cases I might suggest a hybrid approach, where straight SQL is used only where required, so areas of the application that don’t require heavy data processing or top performance are easier to build and maintain.

Now later I came to realize that, in .net 2.0 anyway, all the services and their arguments were created in proxies with their own name spaces, and the proxy arguments had only public fields, not properties so couldn’t bind to them. This prompted me to create wrappers around all .net 2.0 services to transform arguments and returns types to common objects and such. Windows Communication Foundation (WCF) came along and took care of all these issues for me. Still, even with the introduction of WCF I was pointing my trusted IDE at a WSDL for the most part, and it was doing it’s client proxy magic. I still needed no jedi like WSDL knowledge, although to configure WCF I know actually did need to know something about XML (especially setting up certificates and error handling).

Now we come the world of Restful services. No more WSDL, but also, no more proxy magic! I can’t point my trusted IDE at a URL and have things done for me. Now I have to actually do things for myself, sort of. It seems most publishers of Restful services (Amazon, Netflix) give you documentation about their API, so you can consume their services directly yourself, but they also provide client implementations in popular platforms, so you don’t have to write code against the restful API yourself if you don’t want to. It’s probably better since I think I have more faith in client proxy code created by the publisher of the Restful API then I do with the code generated by my trusty IDE. Plus I can look at and makes sense of the communication in an interaction with a Restful API. SOAP was always a mystery, especially when it came to authentication.

Now as we start publishing Restful services ourselves on my current project, I’m eager to publish client proxies for those that will consume them. I Feel like I’m returning the favor of the Restful services we’re consuming by using client proxies provided by the service itself. We are using WCF to host or Restful services and that in itself has some interesting nuances. Microsoft publishes a Restful WCF starter kit, which is useful to get up something that requires very little configuration. We quickly ran into problems when needing to configure our service to use HTTPS and authentication and ended up abandoning the starter kits base service object WebServiceHost, for the traditional WCF ServiceHost configured with a WebHTTPBinding and WebHTTPBehavior.  Using these allowed us to configure our Restful Services with the same XML constructs we used in our SOAP based WCF services.

The above is why we choose LLBL and we have been please with the LINQ implementation.  When using LINQ, however, it is important to keep in mind who is the daddy of an IQueryable or IEnumerable you are working with. 

I recently came across a scenario like the below where I retrieved a result set  and then further refine the result set.

//--query against IQueryable that is LLBL Entity
var codes = from c in companyQ
                 where c.CompanyID == companyID
                 select c.PromoCodes;

if (codes.Count() > 0)
            {
               //--get the freetrial from result set
                var freeTrial = codes.Where(c => c.CodeType == (int)CodeTypeEnum.FreeTrial).SingleOrDefault();

              //--get list prepaid from result set
                var prePaids = codes.Where(c => c.CodeType == (int)CodeTypeEnum.PrePaid);

      }

What I didn’t expect was that the second refining, which I meant to happen to the result set in memory, actually spawned another query in the database.  Once I realized this it made sense, since the DataProvider for the IQueryable I was working with was the LLBL Gen Pro Implementation, and it is supposed to query against the database.   To do what I intended I converted the result set to a List before doing my refining which allowed the DataProvider to be the DataProvider underpinning LinqToObjects.  This then did what I wanted and queried against the data in memory.

//--query against IQueryable that is LLBL Entity
var codesFromDB = from c in companyQ
                 where c.CompanyID == companyID
                 select c.PromoCodes;

//--convert to list based Queryable so
//   further refining done in memory

var codes = codesFromDB.ToList().AsQueryable();

if (codes.Count() > 0)
            {
               //--get the freetrial from result set
                var freeTrial = codes.Where(c => c.CodeType == (int)CodeTypeEnum.FreeTrial).SingleOrDefault();

              //--get list prepaid from result set
                var prePaids = codes.Where(c => c.CodeType == (int)CodeTypeEnum.PrePaid);

      }

The lesson I learned here was keep in mind who owns an IQueryable or IEnumerable when using it, or you might end up with some unexpected side effects.

Since we want to avoid any leakage of application information in the case of an error, we’ve taken the approach of putting a try/catch block around all functionality in a page method. In the case of an error we log the original error and then throw a friendly exception so the jQuery AJAX caller knows something has gone wrong, but get no exception detail. Here’s an example:

[WebMethod]
        public static string SaveCustomerInformation(string customerID,
                                                string customerCode,
                                                string reasonForCall,
                                                string description)
        {
            string returnValue = string.Empty;
            try
            {
                bool isValidcustomerCode = true;
                customerCode = customerCode.Trim();

                //--validate input data
                if (!string.IsNullOrEmpty(customerCode) && (customerCode.Length < 3 || customerCode.Length > 15))
                {
                   throw new WebMethodException(Content.ReusableContentHelper.customer_CODE_LENGTH_ERROR);
                }
                else if (!string.IsNullOrEmpty(customerCode) && customerCode.ToLower().Equals(customerCodeLoginHelper.SERVICE_REQUEST_customer_CODE))
                {
                    throw new WebMethodException(Content.ReusableContentHelper.customer_CODE_CANNOT_USE_REQUESTED_ERROR);
                }
                //--End Validation

                //--Do Work
                CustomerImpl customerImpl = new customerImpl()
                {
                    customerID = int.Parse(JavaScriptHelper.DecryptValueAndHtmlDecode(customerID)),
                    customerCode = customerCode,
                    customerName = reasonForCall,
                    customerDescription = description
                };

                Factory.GetCustomerServices().SavecustomerInformation(customerImpl, currentUser);
                //--End Work                

            }
           catch (Exception e)
          {
               //--Log Exception
                Logger().LogException(e, ErrorLogImpl.ApplicationTypeEnum.Website, RidgeTool.BusinessInterfaces.Enums.SeverityLevelEnum.Error, HttpContext.Current.Request.Url.PathAndQuery, "customer.SavecustomerInformation()", currentUser);
               //--Throw Friendly To Caller
                throw new WebMethodException("An error occured in SaveCustomerInformation");
          }
          return returnValue;
        }

In our javascript we wrap all AJAX calls in a common method allowing callers to provide a method to handle processing if an error occurs, and if no error handler is passed then an common error handling routine is run showing an alert box telling the user a problem has occurred. Here’s what our jQuery AJAX call wrapper looks like.

function AJAXCall(url, data, successCallBackFunction, errorCallBackFunction, completeCallBackFunction)
{
    data = JSON.stringify(data, UndefinedValueCheck);

    $.ajax({
        type: "POST",
        url: url,
        data: data,
        contentType: "application/json; charset=utf-8",
        dataType: "json",
        error: function(xhr, status, exception)
        {
            var err = eval("(" + xhr.responseText + ")");
            if (errorCallBackFunction != null)
            {
                errorCallBackFunction(err.Message);
            }
            else
            {
                alert(err.Message);
            }
        },
        success: function(result)
        {
            if(successCallBackFunction != null)
            {
                //--eliminates .d from return values
                if (result.d != null)
                {
                    successCallBackFunction(result.d);
                }
                else
                {
                    successCallBackFunction(result);
                }
            }
        },
        complete: function()
        {
            if(completeCallBackFunction != null)
            {
                completeCallBackFunction();
            }
        }
    });
}

As you can see the user can choose to provide or not provide an error handling function and if they don’t user still is alerted a problem has occurred.

Here’s an example of our jQuery AJAX wrapper in use:

 var text = $("#testingJavascriptTextBox").val();
            var passedData = "{'testString': '" + replaceForJavascript(text) + "'}";
            var postData = new Object();
            postData.testString = text;

            AJAXCall("/WebMethods/Tags.aspx/TestingReplace", postData, function(textInput)
            {
                alert(textInput.d);
                $("#testingJavascriptSpan").append(replaceForHTML(textInput.d));
                $("#resultsJavascriptTextBox").attr("value", textInput.d);
            });

What all this means is that we protect ourselves form leaking application details in errors by never allowing a naked error to pass through an AJAX call to our web clients. We still alert our AJAX caller to the existence of an error, so we can still know on the rare occasion (hopefully) when one happens!

//definition of our real AJAX Server Caller
function AJAXServerCaller()
{
      //this created public method that can be called by our code
      this.MakeServerCall = function(url, data, successHandler, errorHandler)
     {
      var dataCleaned = JSON.stringify(data);
    $.ajax({
           type: "POST",
           url: url,
           data: dataCleaned,
           contentType: "application/json; charset=utf-8",
           dataType: "json",
           success: successHandler(result.d),
           error:function (xhr, ajaxOptions, thrownError){
                   if(errorHandler != null)
                        errorHandler(thrownError);
                   else
                        alert('An Error Has Occurred');
                }
        });

    }

}

We house our server caller object in a AJAXServerCaller.js file, and this file is included when any calls are made that use the object to make an AJAX server call in their javascript. In order to make an AJAX Server call an instance of the AJAX server calling object is passed in to a method as a parameter.

//example usage of ajax server caller

//function to handle successful return of AJAX call
function UpdateCustomerSaved(serverData)
{
      ///...do something to UI after ajax call completes successfully

}

//function to handle error result of AJAX call
function DisplayErrorCustomerSave(errorData)
{
      ///...do something to UI to notify of error
}

function SaveCustomerData(customerData, ajaxServerCaller)
{
        //acutual AJAX processing handed off to our server caller object
        ajaxServerCaller.MakeServerCall('http://portal/customerSave.aspx?SaveCustomer', customerData, UpdateCustomerSaved, DisplayErrorCustomerSave);
}

///Click Handler calls save method, creates and passes in server caller instance
function CustomerSaveClickHandler(event)
{
       var data = GetCustomerData();
       SaveCustomerData(data, new AJAXServerCaller());
}

When we’re testing any javascript that uses our AJAX server call object we simply include a file called ‘AJAXServerCallerMock.js’ that has an object that has the exact same signature as our real AJAX server calling object, but has an extra property for fake data to be returned by a service call. When testing the instance that is created is now of our mock AJAX server caller and javascript logic that relies on server calls can now be tested without actually hitting a server.

//definition of our mock AJAX Server Caller, must have same object name and
//also the MakeServerCall method defined to act in place of real object
function AJAXServerCaller()
{
     //properties to hold fake data to return
     //and indexes so can do multiple calls in one test
     this.SuccessResultDataArray = new Array();
     var usedMockSuccessResultIndex = 0;

     //we'll allow an error to be programmed on a specific call
     this.ErrorOnCall = 0;
     this.ErrorResultData = null;
     var totalCallCount = 0;

      //this created public method will fake real server call, pass back preprogrammed data.
      this.MakeServerCall = function(url, data, successHandler, errorHandler)
      {
         totalCallCount++;
         // act as if error returned if programmed to do so
         if(this.ErrorOnCall == totalCallCount)
         {
             if(this.SuccessResultDataArray.length<=usedMockSuccessResultIndex)
              {
                  errorHandler(this.ErrorResultData);
              }
         }
         //call success method with data matched to  index of call
         //and increment method call index.
         else
         {
              if(this.SuccessResultDataArray.length<=usedMockSuccessResultIndex)
              {
                  successHandler(this.SuccessResultDataArray[usedMockSuccessResultIndex]);
                  usedMockSuccessResultIndex++;
              }
             else
              {
                  throw 'no success data available at index:' + usedMockSuccessResultIndex;
               }

            }
         });

    }

}

One issue with our approach is that our mock AJAX server call in testing is not exactly like the real AJAX call would be since the mock object is not asynchronous. Our mock caller simply fires the functions passed to handle the ajax server result with the programmed mocked return data. This hasn’t been a large issue, but might be problematic down the line. Another issue could also arise if we need to support complex return scenarios with our mock, like multiple return values, or checking the number of calls made. We will have to build a more complicated mock AJAX caller if we run into situations that require more complex mock object programming.

//example testing using QUnit taking advantage of ajax server caller

var glbSuccess = false;

//function to handle successful return of AJAX call
function UpdateCustomerSaved(serverData)
{
      glbSuccess = true;

}

test("Test Save Customer Data calls server", function() {

    // -- if AJAXServerCallerMock.js is included for test this should be our mock
    var ajaxCaller = new AJAXServerCaller();

     //-- program mock return value for one expected call
    ajaxCaller.SuccessResultDataArray[0] = "{result:0}";

     //--Act
     SaveCustomerData(data, ajaxCaller);

    //--Assert - check everything ok with ui.
    ok(methodToCheckCustomerInGoodState());
});

Between unit testing and adding dependency injection into our javascript it’s already beginning to look and feel a lot more organized. My hope is this will allow us to produce higher quality javascript code, in less overall time. We shall see!

Since we are using more and more javascript why not reap the quality benefits of good unit test coverage here as well?  Considering javascript is non-typed and allows the running of strings as code through the ‘eval’ function it would seem even more important to have good unit test coverage of our javascript.  Up to now we’ve ignored it since it’s been considered UI and not really logic.  With more and more ajax integration this no longer seems like a good practice.

For jQuery driven functionality we have been using the jQuery $.ajax method to call down to asp.net pagemethods located  in web forms we created to support the jQuery functionality.   ASP.net pagemethods are essentially webservice calls located in a webform.  The calls have to be static and must be decorated with the [Webmethod] attribute.   Here is a great blog post going into great detail about exactly how to call an ASP.net pagemethod from jQuery.  We essentially are doing the same thing.  We’ve actually wrapped our $.ajax call so we can centralize error handling and abstract away the ‘.d’ return value you get when the pagemethod does it’s json serialization.

This post is about testing, however, so enough with how we’re using jQuery ajax.   From a testing perspetive what we wanted to be able to do was achieve the same test coverage in our jQuery and javascript as we have on our server side logic.   A little googling and what did I find, but qUnit!  The motif is almost the same as writing tests for nUnit, and when you run your tests qUnit provides default css so test results are shown in a html page in a very similar manner to how the nUnit client shows it’s test results.

The great thing is how easy this is to accomplish.  All you need to do is write tests in a .js file that exercise the code you wish to test using the qUnit syntax.  Then in a html page include jQuery, qUnit, the code you are testing and your test code.  In the html provide the nodes that qUnit will want to write to and, you’re done.   Here’s a very simple html example:

<html xmlns="http://www.w3.org/1999/xhtml" >
   <head>
      <title>QUnit Test Example</title>
        <!-- css from qUnit to make output look good -->
          <link rel="stylesheet" href="http://github.com/jquery/qunit/raw/master/qunit/qunit.css" type="text/css" media="screen">
     <!-- jQuery and qUnit include -->
       <script type="text/javascript" src="/scripts/jquery-1.4.1.js" ></script>
       <script type="text/javascript" src="http://github.com/jquery/qunit/raw/master/qunit/qunit.js"></script>
        <!-- javascript you are testing include -->
       <script type="text/javascript" src="/scripts/ControlScript.js"></script>
        <!-- tests you wrote include -->
       <script type="text/javascript" src="/scripts/ControlScriptTests.js"></script>
   </head>
  <!-- nodes qUnit will write to -->
   <body>
       <h1 id="qunit-header">QUnit Test Suite</h1>
       <h2 id="qunit-banner"></h2>
       <div id="qunit-testrunner-toolbar"></div>
       <h2 id="qunit-userAgent"></h2>
       <ol id="qunit-tests"></ol>
   </body>
   </html>

Very code I’m testing:

function SetupButton(buttonID, txtBoxID, displayText)
      {
         $("#" + buttonID).click(function() {
                  $("#" + txtBoxID).attr("value", $("#" + txtBoxID).attr("value") + ' ' + displayText);

            });
     }

And here are the tests I’m running:

test("SetupButtonTest()", function() {

    var btn = document.createElement("input");
    btn.id = "btn";

    btn.type = "button";
    document.appendChild(btn);

    var txt = document.createElement("input");
    txt.id = "txt";
    txt.type = "text";
    document.appendChild(txt);

    SetupButton("btn", "txt", "disp");
    $("#btn").click();
    equals($("#txt").attr("value"), " disp", "text box has display value: " + $("#txt").attr("value"));

})

test("SetupButtonTest2()", function() {

    var btn = document.createElement("input");
    btn.id = "btn";

    btn.type = "button";
    document.appendChild(btn);

    var txt = document.createElement("input");
    txt.id = "txt";
    txt.type = "text";
    document.appendChild(txt);

    SetupButton("btn", "txt", "disp");
    $("#btn").click();
    equals($("#txt").attr("value"), "disp", "text box has display value: " + $("#txt").attr("value"));

})

As you can see qUnit provides a pretty straightforward way to unit test the now more complex javascript we’re writing in our project (the above is just an example, not actual code from our project). The next step is to integrate qUnit into our continuous integration. We would like to have our javascript tests run with every check in, just like our server side tests do. Here is a post on how to do it, it’s seems a little complicated. I will give it a try and put up a post as to the results.

Hopefully we will be able to bring the benefites of good unit testing coverage out from just our server code and now apply it to the more and more complex client side code we’re creating.  After all why would it not be good practice to test code just because it’s javascript?  It seems even more important to test in a language that is non-typed and allows run-time execution of strings as code.

Below are my notes from the sessions I attended.  I also have to note my favorite quote from CodeMash.  Barry Hawkins was giving a presentation on Domain Driven Design.  When trying to describe the experience of talking to Doman Driven Design people about Domain Driven Design, (apparently they can be long winded in their explanations)  he said something like, “it’s like talking to Ents with crack pipes”.  I liked that description a lot!

Session Notes:

Engineering Vs Design

Domain Driven Design

Software Design and Testablity

User Stories Closing The Agile Loop

Keynote – Lean Methodology

Agile – Iteration Zero

Practical B/TDD

Fundamentals Of Software Engineering

Reviewing Web 2.0 and RIA’s, things like Google Maps, could they have been envisioned by a designer with no software knowledge or vice versa?  Probably not.  Must have design and engineering mixed together in ways not previously needed.  UI Engineering is design and design is UI Engineering.

Traditional Roles in product development: Designers, UI Developers, and web UI developers.  More and more you are seeing people who can do all of these tasks as need to understand them all.  New breed of tools to simplify this sort of work, RIA Design tools:  Adobe Catalyst, JavaFX Production Suite.

Important to cross train engineers and designers as they function with very different processes.  Important to educate engineers on the design process and designers on the engineering process to encourage mutual skill appreciation.  To this end co-location is very helpful.  Much easier for designers and engineers to understand and support each others processes if they are situated together.

Important to understand the difference between prototype and production.  Build many prototypes and be willing to throw them away.  Joe likes to use a separate folder in subversion for design, partly because subversion is good at handling design type resources and partly to separate highly iterative resources.   The design folder is prototype work, not production.  Also brings benefit of version control to design, where it is not traditionally used.

Build detailed facades.  These are generally not going to be production code, be ready to throw much of it away.  Really iterate to get it right.  Stub out back end calls and keep back end people in the loop.  Make sure the UI team has regular check ins with the back end team.

Once you’ve iterated to the point where can start work on production code can lift much of the final iteratino prototype code to start production work.  Keep prototypes clean by doing production work in separate source control folder.

Joe seems to be wrapping up although still 20 minutes left in the session.  I think we’re going to Question and Answer now.  Question came up as to how to get end users to not focus on color and such when reviewing a functional wire frame?  Joe’s answer, keep all design detail out of functional wireframe so nothing for end user to get distracted by.

Wire frame prototyping should happen before visual design.  Designers need app functionality to be fairly solid before they can effectively begin their work.  Interaction and functionality should be defined thoroughly before visual design.

Well that’s a wrap.  Another good session, not very technical but very relevant to our current work.

The presentation focused on the importance of modeling.  To distill this greatly models are a representation of the domain, the domain is the subject matter itself.  It is important to use ubiquitous language across a team made up of all people necessary to move project from conception to completion.  This means that subject matter experts and scenarios they provide feed the domain vocabulary, not pattern and practice leanings.

Domain models should start small and be validated by detailed reference scenarios.  Barry’s team uses nNuit or jUnit to create tests to in effect ‘model’ the reference scenarios so they can validate the model accurately reflects them.  The reference scenarios get increasingly complicated and are provided by domain subject matter experts.  Barry used an example from the shipping industry as an example.

Another importance concept was to entertain different models, don’t settle on the first solution you think of.  Use natural language to pseudo code out multiple modeling options to decide which is best for the context you’re in.  Don’t be afraid to throw out models if they don’t work, the first thing isn’t the best thing necessarily.

Barry works with Eric Evans who authored a book, Domain Driven Design, which the talk was based on.  Great overview of a very deep topic.  I’m looking forward to picking up the book and learning more.

Testability and Design …is about finding, removing and preventing defects….is about assiging and partitioning responsibilities in an application…corresponds well to traditionally good design ideas…..is facilitated by patterns.

Need to shift mindset, I don’t write code, I ship software….people should see their efforts in the context of the whole, testability promotes this.  Software isn’t designed for the efficiency and optimzation of the code itself, but for the software as a whole.   Good code is only important in that it enables us to delivery what the customer wants, where it does not do that it doesn’t really matter.  That being said it is really important since good code allows software to be changed and worked on by other developers more easily, allowing us to better deliver wanted features to our customers.

First Causes Of Good Design: Fast feedback, short iterations are important to good design (agile)……Orthogonality, good separation of concerns (persistence, ui) so changes can be kept to small parts of the system when made.  Changes will be needed when made only want to change one area of system to accommodate.  This allows you to change things more easily when you know more later in your project.   You will be wrong at times, this helps make things easier to change to accommodate this…………Reversibility, give customers the ability to change their mind………….Understandability, although smaller classes for testing that interact more may make things less understandable.

Writing Automated Tests:  Known Inputs and Measurable Outcomes.  State Based tests versus Interaction Based tests, state based tests check to see if state changes occurred appropriately, testing to see if something else was called appropriately are interaction based tests (mock objects).

What makes a good test?  Repeatable…..Run Fast…..Easy To Write….Easy To Understand, a good test tells you where and why it failed, not just that it failed.

Jeremy is pulling up an example of something he did early on that was not testable.  Showing us the actual code.  Example code is doing many things at once, hitting database and doing processing.  Code is impossible to test without setting up entire application.

You should isolate the ugly stuff, isolate external dependencies ie the database, active directory, remoting, chatty api’s, etc…..etc……  Jeremy gave an example from Jay Flowers, Expand The Creamy Center.   Jeremy is now walking through how to do this with the sample bad code he has up on the screen.   Refactoring code into state machine that is heart of the workflow, ugly stuff is pulled out and state machine is tested using mocks for the ugly stuff.

Coding from the bottom up is good idea.  Test small to begin with, then test big.  Don’t try and put everything together and then test, hard to find problems you find.  Build little things at a time and assemble them.  Jeremy is a big fan of Object Role Stereotypes and responsiblity driven design, this is in the context of introducing a controller into his refactoring of his example code.

Inversion of control discussion.  Should push not pull, if your class is directly accessing a config file or database it is very tightly coupled to these things and hard to test.  Push externally needed things into your classes so they aren’t coupled to these items.  Push don’t pull!  This also causes you to keep a short tail, can resuse code without needing a whole lot of other code to come with it.

The hour is up, a very good presentation I thought.  The push versus pull analogy really made a lot of sense a clarified why we’re doing a lot of the things we’re doing.