beware API overloads

on business object methods like Consumer.UpdateConsumer() we have several overloads that let you update only a few specific Consumer properties. for example, there’s one overload that takes a CustomerStatusId, another that takes a WhereHeard and a CustomerStatusId, etc. these overloads all call a common, private updateConsumer() function that takes care of the database update, and they pass in the object’s properties for the fields you are not updating, so that the original values are preserved.

however, this means that if you call an overload that takes multiple parameters, any value you pass in as a parameter will be used for the database update. so passing in “null” or empty string will update the database with “null” or empty string for that field, which may not be your intention--

Tutor.com Classroom How-To #4: enforcing an MVC-style architecture

These How-To tips are taken from The Tutor.com Classroom: Architecture and techniques using Silverlight, WPF, and the Microsoft .NET Framework.

You can check out the Silverlight Tutor.com Classroom in "practice" mode, although the real experience is with a live tutor on the other side!

The benefits of MVC-style architecture are numerous: testability, modifiability, simplicity of design, etc., and WPF/Silverlight Xaml “binding” provide an ideal structure to effectively detach the front-end from middle-tier business objects.

One simple way to enforce MVC-style architecture is to put classes with distinct responsibilities in separate assemblies, and add the minimal set of references only as required by each assembly. This enforces the principle of separation of concerns, since you’ve actually made it impossible for code in one assembly to be concerned with the business of another if it shouldn’t!

Tutor.com Classroom How-To #3: specifying "End-Of-Message" to a TCP/IP listener

These How-To tips are taken from The Tutor.com Classroom: Architecture and techniques using Silverlight, WPF, and the Microsoft .NET Framework.

You can check out the Silverlight Tutor.com Classroom in "practice" mode, although the real experience is with a live tutor on the other side!

Since a TCP/IP Listener is constantly in a listening state, the Listener needs to know when to act on the bytes received. To accomplish this, listen first for 8 ASCII bytes that represent two 32-bit integers specifying the number of bytes the sender is sending, and then continue listening until receiving this number of bytes. This is an easier solution to implement than using a delimiter to specify end-of-message, since you don’t have to worry about delimiter escaping, and since you can specify the exact number of bytes to listen for via the third parameter to SocketAsyncEventArgs.SetBuffer().

properties vs. functions

although there’s little difference after compilation, treat properties and functions very different from a logical perspective. properties should almost always be deterministic, i.e. calling the same property twice should return the same value (so object.Property == object.Property must be true). a property can have a lazy get constructor, so it actually does some work the first time it is called, but it must remember the result of that work and return it on subsequent calls. so in general a property returns something stateful or something static.

in all other cases, use a function, and give it a meaningful name based on what it’s doing (i.e. GetRandomNumber(), CreateUser(), etc.).

remember IE6

kind of goes along with the 1024x768 note: IE6 still accounts for 40% of our IE visits, and IE as a whole accounts for 80% of site visits. this means about 1 in 3 of all site visitors see what we do using IE6. this # is declining, but it’s still very much in play for now, so remember to check your work in IE6 in addition to IE7/Firefox. unfortunately, there are subtle differences in the IE rendering engines, and some things that work fine in IE7 just don’t in IE6.

when Firefox 3 comes out (fairly soon), we’ll have yet another browser to add to the make-sure-you-test-on list; ahhh, web development J

when doing GUI work, run your second monitor at 1024x768

remember that most of the world sees things very differently than we do, so make sure you frequently check your GUI work on a 1024x768 display; it’s still half of users. recent stats from our site:

1	1024x768	47.56%
2	1280x800	16.57%
3	1280x1024	10.05%
4	800x600	8.81%
5	1440x900	5.05%