Monday, August 31, 2009

On the Evils of ObjectContainerDataSource with MVP Pattern

Oh my head is hurting after banging it against the wall for a while now. I've been working with the Web Client Software Factory, and started using the ObjectContainerDataSource class to try to bind some of our model to the view. All was going well, until I found the fine print from the How to page on the ObjectContainerDataSource. That's when I started becoming very angry.

Here's the fine print:

Instance. This is the data object. The ObjectContainerDataSource control uses reflection to create this object (on every update operation, delete operation, and insert operation) and populates it with the input data from the data-bound control.


Huh?

Why on this green ball on which I sit would I want a reconstituted object populated with only the data that was bound to the form?

Don't they understand that there might be more data here I want to maintain? The issue, as far as I can tell, is that the MVP pattern is expecting that the object you bind to the UI will have absolutely nothing but the specific properties that show up on a FormView. This isn't true. I might want to reuse the same object (staying DRY and enabling object reuse. Somehow, I gotta use the same object, so I have a few options:

1. When I hit the point of updating the object, ignore the instance that the ObjectContainerDataSource creates, and simply fetch the old object from the services, checking each property (perhaps via reflection) and setting the properties that have changed onto the object in question. This is obviously a bad idea for several reasons. First of all, that means I'm going to have to make another call to the database, adding more time to the update. I don't want to do that. Also, I'm going to have to write some funky reflection code to compare all the values. This is more work than it's worth.

2. Store the object in state, and retrieve it. That's a nice idea, but what if this whole MVP pattern is being implemented on a user control and I'm planning on having more than one of these controls on a specific page? That won't work either, as the instances will overwrite one another.

3. Completely and totally override the ObjectContainerDataSource and ObjectContainerDataSourceView and make a new one. One desperate programmer has already tried this and I nearly did too, but I felt the solution was a little bit bloated for my needs. Again. I'm lazy.

4. Drop the whole thing, fetch the items from the database, and manually set the value from each and every field in the FormView to the object. Nah. Not gonna do that.

So what was the solution I came up with? I'm sure most of you are hanging on the edge of your seats with bated breath.

I ignored the entire Updated event entirely.

Here's why. The Updated Event comes with the ObjectContainerDataSourceStatusEventArgsobject, while the Updating event comes with the ObjectContainerDataSourceUpdatingEventArgs object, both of which would make Steve McConnell choke because of their names. Nevertheless, they're very different objects.

The ObjectContainerDataSourceStatusEventArgs provides two properties: Instance, and AffectedRows. Instance is the reconstituted (regurgitated?) version of the bound object, while AffectedRows tells you how many fields the user changed before he/she submitted. Yeah, both of those are pretty useless.

Contrast that with the Updating event. The Updating event offers you the Keys property, and the NewValues and OldValues Dictionaries, along with the Cancel property to cancel the update altogether. Ahh, now we can determine exactly what's changed.

Now, buried deep in the framework is a type I found while hunting around called the
TypeDescriptionHelper. This class is the right to ObjectContainerDataSource's wrong.

On TypeDescriptionHelper, there's a poorly named, but very useful method called BuildInstance, which takes an IDictionary and an existing instance of the bound class. It reflects on the bound class and sets the values as indicated in the dictionary you pass in. This method is actually called after the Updating event, but before the Updated event, after ObjectContainerDataSourceView calls Activator.CreateInstance to create an instance of the class you've bound to the form. The only difference is, we're going to call it here.

So what I chose to do is narrow the dictionary down to only those values that have changed, by comparing the OldValues with the NewValues, and then pass the resulting dictionary to the BuildInstance method along with the Person, which, believe it or not, I can get by casting the sender to ObjectContainerDataSourceView, and pulling it out of the Items collection. My final method looks like this:


protected void UpdatingPerson(object sender, ObjectContainerDataSourceUpdatingEventArgs e)
{

var source = sender as ObjectContainerDataSourceView;
var person = source.Items[0] as Person;

Dictionary<string, string> changedValues = new Dictionary<string, string>();

foreach (string key in e.Keys)
{
if (!e.OldValues[key].Equals(e.NewValues[key]))
changedValues.Add(key, e.NewValues[key] as string);
}

TypeDescriptionHelper.BuildInstance(changedValues, person);

_presenter.SavePerson(person);
}


This UpdatingPerson method is the handler for the ObjectContainerDataSource's Updating event, and I don't handle the Updated event at all.

Another advantage to this method is the fact that I'm not setting anything that hasn't changed. I leave all the other properties alone. As they should be.

Friday, August 28, 2009

BinaryFormatter: Fields, Properties or Both?

I ran into the second person today who was confused on this concept, so I thought I'd post the answer here. For those of you who missed the question it is: "When I serialize an object, does it only serialize properties, or does it serialize the fields also?".

Well, the answer depends on how you serialize the object. For this post, I'm only going to talk about the BinaryFormatter. XmlSerializer and DataContractSerializer both work differently, reflecting on properties (for XmlSerializer) or properties and fields (for DataContractSerializer). Properties serialized with either the XmlSerializer or the DataContractSerializer will actually call any logic within the properties they're setting. Binary formatter does not. Here's some example code to prove that BinaryFormatter will leave your properties alone:


using System;
using System.IO;
using System.Runtime.Serialization.Formatters.Binary;

namespace ConsoleApplication31
{
internal class Program
{
private static void Main()
{
// create an instance of the object
var thing = new StrangeThing();

// set the value.
thing.SetValue(5);
Console.WriteLine("Initial value is {0}", thing.Value);

// serialize our object.
var formatter = new BinaryFormatter();
var stream = new MemoryStream();
formatter.Serialize(stream, thing);
stream.Position = 0;

// Deserialize the object. If this is calling setters, it should throw.
var thing2 = (StrangeThing) formatter.Deserialize(stream);

// Output the result.
Console.WriteLine("After deserialization, the value is {0}", thing2.Value);
Console.WriteLine("Setter was never called");
}
}

[Serializable]
internal class StrangeThing
{
private int _value;

public int Value
{
get { return _value; }
// make the setter throw.
set { throw new NotImplementedException(); }
}

// another method to allow us to set the value.
public void SetValue(int value)
{
_value = value;
}
}
}


The binary formatter establishes the actual "binary" representation of the object. The assumption with binary formatter is that, if the fields are all serialized, the properties will work as expected, because properties are nothing but fancy methods, basically. Thus, the BinaryFormatter only serializes fields, and never properties.

Incidentally, serializing only fields is a great way to make a DataContract in WCF. Should you desire, against my earlier admonitions never to make your business objects data contracts, at least do yourself a favor and never set your properties as DataMembers, only decorate the fields.

Wednesday, August 19, 2009

Understanding Escape Characters (For Beginners)

I had a question asked on the forum recently about escape characters, and since this is a rather frequent question for C# beginners, I've chosen to reproduce the material here. If you already understand escape characters in string literals, you can stop reading now.

Let's say that I have to write a computer program that reads a string character by character. I've decided that I need to use double quotes to signify the beginning and the end of a string. Knowing this, I can represent the string

bob

in my code file by typing:

"bob"

Great, no problem. But, what if I want to signify the following:

Bob says, "Hello."

Now I have a problem. The text I want to represent contains a quote character. So doing this won't work:

"Bob says, "Hello""

Because, the quote signifies the beginning and the ending of ths string. So what do I do? I use a special character that means "the next character should be considered part of the string, and not signify the beginning or the end of the string. I'll make that character be a "\". So now, I can type the following to represent my desired string:

"Bob says, \"Hello\""

Preceding the quote symbol with a backslash means that the next character is going to be a quote that is considered part of the string, not the end of the string. Not preceding it means that I'm signifying the end or beginning of the string.

Now that I've done that, I have another problem. What if I want to represent the escape character (the "\" character)? For example, what if I have a string like the following:

C:\Program Files\Morton\

Because I've redefined my backslash to mean that the next character is to be taken literally and not as a bounds to the value I'm trying to represent, how do I represent the "\" character itself?

To do this, I follow that backslash with another backslash to represent the end of the string. So now, to represent the string, I do this:

"C:\\Program Files\\Morton\\"

The above format is what the C# debugger will show when you hover over a particular string variable containing the text:

C:\Program Files\Morton\

In other words, it shows the value as it would need to be written in the source file, and not as it actually is.

So what about when you need to represent the following text:

When two backslashes (\\) are together, it means we want to represent a single "\" character.

How would you format that in the source code? Like this:

"When two backslashes (\\\\) are together, it means we want to represent a single \"\\\" character."

Confusing, I know, but the idea is still the same. My actual text I want to represent contains two backslashes in succession, so to represent that, I'd have to put four backslashes in succession. Also, note how the characters following "single" and before "character" are represented, by using a backslash, quote, backslash, backslash, backslash, quote respectively.

This is what it means to escape a string. Though string appear escaped in the debugger, this does not add to their length. The runtime still recognizes an escaped character as simply one character and not two. In other words, it does not take into account the escape character (\) when calculating the length of the escaped character (\\).

This is how C# regular literals are represented. This is needed in order to ensure that the compiler, which reads a string line by line, can understand the programmers intention, that they intend to enter a literal quote character versus simply ending the string. I hope this helps to understand the concept.

Tuesday, August 11, 2009

Houston F# Users Group - August 27th 7:00 PM

The Houston F# Users Group for August will be taking place August 27th at 7:00 PM in the Catapult Systems Training Room. We'll be having an interactive, hands-on session where we'll actually get to code some F#. All levels of knowledge are welcome, and there will be food!

Catapult Systems Houston
10370 Richmond Avenue
Suite 1250
Houston, TX 77042


View Larger Map

We're the building on the left lower corner of the map (the southwest most building on the north east corner of Richmond and Beltway 8) on the 12th floor.

See you then!

Tuesday, August 4, 2009

What is Code Quality Anyways?

Since I was young, my father has encouraged me to become a writer, so a few years ago, I entertained the idea, and bought a book by Stephen King called "On Writing". From it, I learned several aspects of good writing. One of the most memorable was to avoid adverbs ending in -ly. The reason they should be avoided is because your verbs, nouns and adjectives should describe your intentions without the use of adverbs. Adverbs are extra fluff, and when overused, are the mark of an immature writing style.

Until I read that book, I never thought about the importance of one sentence. A good novel writer ensures that his audience is not subjected to needless modifiers that serve to support poorly written sentences. Not only this, but he does it on a consistent basis, one sentence at a time, until the entire novel is written, all the while focusing on the overall plot of the book. The mark of quality in a novel is it's ability to move the plot forward while avoiding unnecessary distractions. This hallmark is established with each and every sentence.

In the publishing world, there are checks and balances to ensure that before a novel is released, the quality of the novel matches up to certain standards. After the novelist writes the novel, he sends the manuscript to the publisher, who typically suggests one or many edits that the manuscript needs before it's ready to be published. The novelist then edits his manuscript and repeats this process until the book is ready to publish.

Now, liken yourself to a novelist. You have a novel (your code) full of sentences (lines) that you're tasked to write. The assumption is that you will not only focus on the purpose of the application, but will also focus on how that purpose is to be achieved, by paying attention to each and every line of code. I've heard it said recently that "it only takes one line to create a dependency". This statement shows the power that one line of code can have. It can make or break your application.

So what is code quality? Quality code can only come from paying attention to each line you write. As I'm writing this blog, I'm paying attention to each and every sentence I write. I'm reviewing each one to verify they communicate my point clearly and concisely. The reason I'm doing this is because I know there are people who will read this post. They'll analyze what I'm saying, and won't want to waste their time while reading it. They expect to learn something from every sentence.

So why don't we do this as much in our code? I think it's because we believe that our code will never be read. It will only be used. This is a false assumption that needs rejecting. Every day I read the code I've read in order to modify it, or in order to hunt down a bug. The way the code is written is almost as important as what it does. Poorly written code takes longer to maintain. Well written code can be maintained almost effortlessly.

Each line of code should serve a purpose. Each set of lines should be reviewed as it's being written, to ensure the most clear and concise expression of the concept is found. Each architectural construct should be reviewed for it's flexibility and it's contribution to the overall goal. This should happen not in a designated refactoring session, but during the moment-by-moment process of coding.

This takes patience, consistency and the ability to clearly adhere to and express the purpose.

Code quality, in my definition, is a well-assembled collection of well-expressed lines of code, none of them being taken for granted. This is a basic concept, but one that needs reinforcing from time to time. There are so many concepts to quality programming that it takes a lifetime to master them all (if indeed they can be mastered), but for a good start allow me to suggest SOLID principles and design patterns. Professional programmers will learn these techniques and use them to their advantage. Poor programmers will abuse the code and muddle it's intentions.

Refactor in the small, and refactor consistently as you go. A good place to start might be to begin reading Sean Chambers' current blog series entitled 31 Days of Refactoring.

Learn these techniques and apply them as you go, not after the fact, and you'll find at the end that your code can be as enjoyable to read as some of the world's greatest authors, from Hemingway to King to Rowling.

Write code like it's going to be read.

Monday, August 3, 2009

The Wiki is Live

I've finally done it. For a while now I've been looking for a way to organize my thoughts efficiently and effectively, while actually retaining the things I'm learning. The wiki is designed to help with that, and I've been working on it for a couple of weeks now.

Generally I get my information from one of a few sources (in no particular order):

1. Daily life. I learn quite a bit just by programming.
2. Podcasts.
3. Online Forums (most notably the MSDN forums, where I contribute heavily)
4. Blogs I subscribe to.
5. Blog posts people send to me.
6. Talking with people older and more experienced than myself.

Sometimes, I find that while researching this information, there's bits and pieces of information I need in order to fully understand the information I'm looking at, so I'm making a commitment to actually follow these breadcrumb trails to better learn at least a little of the concepts and/or technologies that seem integral to the conversation at hand.

But this presents a problem. What pieces of information am I going to record? Certainly I don't have the time or patience to seek out a full understanding of everything, so I have to limit what information I seek out to the minimum, earmarking things I want to revisit, and remembering the chief point of the rabbit trail that led me to learn that bit of information I'm learning, so I can ultimately accomplish my goal.

The problem is this: I'll have several pieces of information unfinished.

The good news is this: That's the life of the developer, so I'm not alone.

We will never know everything about everything, so the best we can do is learn alot about a little, and the rest we might know a little about. I believe the Wiki expresses this sentiment. There are some things that I know little about, and don't need to know about in depth, so I don't go in depth. In fact, some of the wiki entries are single sentence entries, simply meant as stubs to be fleshed out at a later date, or in some cases, never. Nevertheless, I feel it's extremely important to document my journey, in an effort to help those who might come after me to learn from me some of the things I've learned.

So, after much introduction, allow me to introduce: Coding Light Wiki. Enjoy.

Saturday, August 1, 2009

New Name and Style (and Some Comments on Simplicity)

So I decided to shake things up a little bit... I've had this blog for over a year now, and this morning decided to edit the page... "a little". Well, that got blown to bits when I clicked "Save Template" on Blogger, thinking it would allow me to download and save my current template. "Save Template" actually means "apply the current template". Suddenly my whole blog's color scheme had changed, and I lost all my adjustments.

I also realized my label cloud was completely broken. That hurt me.

So began the metamorphosis. I started editing the templates and finally found a template I liked, and decided in the process to rename my blog to something a little more creative and descriptive than the previous name: David Morton.

I decided on Coding Light. The idea being that code should be light. There are so many "cool" things out there right now in shiny silver boxes, that it's easy to get stuck in the trap of thinking that the right combination of tools can effectively eliminate the difficulty and complexity in programming. Many tools exist for the sole purpose of flexibility. Bob Martin has astutely observed:

The cost of flexibility is complexity. Every time you put extra stuff into your code to make it more flexible, you are usually adding more complexity. If your guess about the flexibility needs of your software is correct, then you are ahead of the game. You've gained. But if you get it wrong, you've only added complexity that makes it more difficult to change your software. You're obviously not getting the payback.


What does this mean? This means we should stop making such an attempt to create the most flexible, catch-all algorithms and frameworks possible, and instead begin focusing on the problem domain. Instead of trying to discover the wheel, start addressing the problem you're paid to solve, and do it simply, directly and without unneeded abstractions (see: YAGNI). This is what it means to "code light". Keep the weight of your architecture and your algorithms light. Don't over abstract. KISS.

Now, don't get me wrong... I love the new stuff as much as the next guy, but the new stuff has it's place. Our primary goal when learning a new framework or a new technology is not to look for places to use it, but to instead figure out where it should be used, while continuing to default to the simplest solution possible. Sometimes the simplest solution is the new language or framework, and sometimes it's not. It's the role of the adventurous geek to learn how to discern the difference.

That being said, welcome to the "re-branded" blog. I have no plans to stop blogging on some of the algorithms and tricks I've discovered or seen other people use, but I do have plans to start increasing posts about coding standards, simplicity, and other language-agnostic thoughts.

Glad you could drop by.

EDIT: Based on a comment by Ben Scheirman, I've decided, despite my love for the label cloud, to remove it completely, as an action to be taken to demonstrate my new commitment to simplicity, not only in coding, but in the design of the site itself. Turns out nobody really used it anyways, so it was just cluttering things up.