In the last post I gave an overview of the sample Silverlight + RIA application (code can be found here). For Part 2, I wanted to talk more about the specifics of the service layer and the order of the calls.

You’ll notice the declaration of several data sources in the constructor of the service:

[EnableClientAccess()]
  public class TicketService : DomainService
  {
    private TicketDataSource _ticketDataSource;
    private CustomerDataSource _customerDataSource;
    private ProductDataSource _productDataSource;
    private ActionTypeDataSource _actionTypeDataSource;
    private ResultTypeDataSource _resultTypeDataSource;
    private TicketActionDataSource _ticketActionDataSource;

    public TicketService()
    {
      _ticketDataSource = new TicketDataSource();
      _customerDataSource = new CustomerDataSource();
      _productDataSource = new ProductDataSource();
      _actionTypeDataSource = new ActionTypeDataSource();
      _resultTypeDataSource = new ResultTypeDataSource();
      _ticketActionDataSource = new TicketActionDataSource();
    }

In our production environment we’re delegating the actual database operations to separate classes that make calls to Oracle Stored Procedures through ADO.NET using an Oracle provider. It doesn’t have to be an Oracle DB of course – you could use any database you like when you just want to hide the details away behind an abstraction such as this. For the sample application, we store the data in memory using the HTTP Session.

Insert: Order Of Operations

What I really wanted to talk about in this post is the order of operations when it comes to doing inserts and saving new entities. For this application we have three pieces of data that can be inserted into the database:

• Ticket
• Customer
• TicketAction

Product, ActionType and ResultType are also data on the Ticket or TicketAction objects, but they are pulled from the database tables as static lookups and only referenced in their parent objects as foreign keys. No new values are inserted into these three tables via the application and that is why they do not have INSERT methods on the TicketService.

Ticket is our root aggregate object. Customer is a child object on the root, and TicketActions are a collection on the root. The order of operations is determined by RIA. InsertCustomer() will be called first, then InsertTicket() and finally, InsertTicketAction(). Let’s see how and why this happens.

Inserting a Customer

All single-entity child objects on the root will have their respective INSERT methods called first. If you think about it, this makes sense. The primary key of each child object is used as a foreign key on the parent object, so the child object primary key has to be known BEFORE the parent object can be saved. Thus, for a new Customer object, we have to first insert it into the DB and return the newly generated CustomerId to the Ticket BEFORE the Ticket gets saved.

public void Insert(Customer customer)
{
    customer.CustomerId = _customerDataSource.Insert(customer);
}

So here we’re passing the Customer to a class that will perform the actual INSERT into Oracle, and in turn that method will get the generated PK from Oracle and return it. It is then our responsibility in this call to associate that PK with the Customer object, because the Customer is going to get sent back across the wire to the client when RIA is done making all these calls.

Inserting a Ticket

Once the Customer has been saved to the DB (and the new CustomerId returned and set on the Customer object) then RIA will call the INSERT method for the Ticket itself. At this point in time we need to set the CustomerId (and any other child foreign keys) on the Ticket object:

public void Insert(Ticket ticket)
{
      ticket.CustomerId = ticket.Customer.CustomerId;

      ticket.TicketId = _ticketDataSource.Insert(ticket);

      foreach (var ticketAction in ticket.TicketActions)
      {
        ticketAction.TicketId = ticket.TicketId;
      }
}

And just like the Customer INSERT method, once we save the Ticket to the database we need to get the generated PK back from Oracle and set it on our Ticket.

Inserting TicketActions

The last thing that happens here is the insertion of multiple TicketActions, as this is a child collection on the Ticket object. And again, if you think about it from a DB point of view, this makes sense. Each TicketAction has a foreign key TicketId. Thus, a TicketAction can’t be saved to the DB until the TicketId is known. For a new Ticket, that won’t be until the Ticket is saved and the id returned. Once the Ticket’s primary key (TicketId) is known, we can attach it to each TicketAction and save them as well. RIA will make that call automatically, after the INSERT method for the Ticket is done:

public void InsertTicketAction(TicketAction ticketAction)
{
      ticketAction.TicketActionId = _ticketActionDataSource.Insert(ticketAction);
}

Done Inserting

Once all of those calls are made and the various pieces of data have been saved to their respective tables, the root aggregate object is ready to be reloaded by RIA. This will happen AUTOMATICALLY. You do not need to call Load() on the service context again in your ViewModel after you have called SubmitChanges(). RIA will automatically reload your entity client-side depending on what kind of LoadBehavior you specified (for this project we’ve specified a LoadBehavior.RefreshCurrent). This is another reason why it is so important to return the primary keys and set those values on the objects when you saved that data to the database.

Next time I’ll cover UPDATE operations and explain one of the quirks of RIA sending entities down the wire….

A couple of coworkers are discussing a bug in the software. In this particular bug’s case, it concerns an icon that appears in a column of a datagrid. Each row in the grid is either supposed to have this little icon in a specified column, or not. It depends on the data. But that’s not really important, just background info.

What’s really important is that the icon was previously coded and tested and worked. It appeared under the correct conditions and was hidden when it should be. Now, all of a sudden, it wasn’t working. We get an e-mail from customers saying, “The icon should show up in this circumstance, but it doesn’t.” Time to investigate.

While my two coworkers are hashing out exactly what could have happened, why, and how to fix it, I start thinking to myself, “There should be unit tests to catch this. This shouldn’t have happened. I’ll just go find the test suite and write a couple new tests to ensure the icon properly displays based on the criteria of the data.”

Sounds easy, right?

As I started digging through the specific class code and examining the unit tests, I notice that there are no unit tests for this functionality. That seems suspicious. Then I notice something else: there’s no code. All that exists is a method call to a service that returns a datatable.

As Alice did, I decided to drop through the rabbit hole and see what’s up.

When I get to the bottom I see a gigantic SQL statement – several hundred lines long. It is embedded in the application, deep down in the data access layer, complete with multiple sub-selects and even an SQL case statement! It’s got multiple parameters in the where clause. It’s the kind of thing that makes SQL admins all warm and fuzzy inside, I’m sure. The whole thing is then handed off to our OR/M, which returns a simple datatable. While it is not a stored procedure, it might as well have been – it only has one step remaining on the cliff before it jumps right off into the database.

And the killer is, it’s untestable.

The caveat here is that this particular stored procedure was written as a performance gain, because the nature of the data requested is complex in its selection. But still, I’m of the belief that there might be a better way to query the data than one giant stored procedure.

Because the minute you put business logic in a stored procedure you compromise the quality of your application. You introduce the capability for your team to make mistakes that are no longer easily caught by a regression suite of unit tests. More importantly, I think, is that you increase the probability of repeated bugs. And to me, repeated bugs are a cardinal sin of programming. Nothing makes a development team look dumber than fixing a bug only to have it crop up again, and again, and again. It makes the software look bad, and by proxy it makes the developers look incompetent.

Personally I think they should clean house on the OS side, put the development tools in maintenance mode for a couple of years, and put Scott Guthrie and the rest of those geniuses behind Visual Studio to work on building a new OS from scratch.

This is something I’ve been saying for years. Windows needs to be rewritten from scratch. Start over, and let the guiding principal be: Simple Is Better.

Windows has become so big and bloated that it can’t do the basics anymore. I mean, really – what do you need your OS to do? I know what I want my OS to do: run my apps. That’s it; it’s that simple. Manage my files, memory and processes so I can run my apps. And even Windows can’t get that right.

Have you tried working with Explorer lately? Copying large files? Over a network? When was the last time you tried to kill a process in Windows? Guess what? It’s still easier and more reliable to kill a process in Unix/Linux than it is in Windows. Why is that?

As Riply said, “I say we take off, and nuke the site from orbit. It’s the only way to be sure.”

Our board has undergone a few makeovers as well over the past couple of years. In the beginning we tried to do what everyone else was doing. We had a big board with several columns. But our shop was small (at it’s peak, three developers and a PM) and the extra columns seemed wasteful. We didn’t really have a QA team, for instance, because we were the QA team. A “Testing” column seemed like a waste because we practice TDD as much as possible, so testing is part of the process of development. Same goes for acceptance tests, hands-on testing and customer approval. It’s all part of the process of developing software. Personally, I don’t look at the different elements – like architecture, design, testing or customer feedback – as separate phases. I see them as the one thing: developing software. They are all necessary elements to reach the final goal of a completed, working, and trusted software feature.

In the end, we finally settled on was the simplest thing that could possibly work: Backlog, In Development & Done.

Our Backlog is every story card in our possession. We don’t categorize; we just let the customer prioritize. In Development is everything we’re working on during this iteration. Since we – the developers – do it all, then In Development carries a comprehensive meaning. And when all the bases are covered, regardless of what order they were performed (although I hope unit tests were written before the code was) then, and only then, does it move to Done.

What I enjoy most about our board is that it is so simple to read. It’s easy to determine what’s left to do (Backlog), what’s being worked on (In Development) and what’s ready for the next publish at the end of the iteration (Done). And I don’t need to worry about testing or customer approval because those elements of the development process are implied.

That all changed today when a colleague – and friend – opted for greener pastures. He’s returning to the company where he started his career as an intern, a place he is particularly fond of, and I cannot blame him for taking a job that more closely fulfills his professional and personal desires. I wish him all the best.

Still, our small team of developers just shrunk by one, and we need to fill the gap.

In a larger city this would not be a problem. We’d just advertise the position and the resumes would pour in. But our location is our biggest hurdle when it comes to attracting talented developers. We simply can’t pull from as large a pool as a city like Austin, Texas can.

So where do I work? Nez Perce County, a small county government in north-central Idaho. As one might imagine, it is not exactly a mecca for software development talent. But that hasn’t stopped us from trying. People we talk to are always surprised to learn that our tiny little IT shop in Idaho is practicing Agile techniques. Yet that is exactly what we’re doing.

We subscribe to Agile practices, Extreme Programming in particular, and we drink from the TDD fountain. We use Continuous Integration, unit tests, acceptance tests, and frequent customer feedback along with short iterations to write quality, maintainable code and deliver business value to our customers (which, incidentally, includes us, since we are also taxpayers; we’re our own bosses in manner of speaking).

We work in an open environment and every developer has two monitors at their workstation. We work closely together as a team and have an on-site customer to help provide rapid feedback.

What We’re Looking For

We realize that we’re a bit handicapped by our geography. We’re not going to see a lot of great resumes. So it’s important for us to identify candidates that have the capacity to learn and possess a passion for software development. Ideally, candidates for our shop would have the following qualifications:

• Knowledge of Object Oriented design and principles
• Knowledge/Experience with C# .Net, or a similar object-oriented language (Java, C++)
• Database experience
• Willingness to learn

Bonus points for knowledge/experience with any of the following: Gang of Four design patterns, Unit Testing, IoC, CAB and/or SQL Server.

More information about the position, including benefits and pay, can be gathered by contacting my boss, Randy Buttenhoff, via the Nez Perce County IT web page.