Joshua's .Net Tips

Just saw this post by Jan Schreuder talking about MSDN Virtual Labs. If you haven't checked these out yet, it's worth it. Without installing the software, try out various Microsoft technologies, both present and future. If you were just dying to try out that new SQL Server 2005 feature, or find out what Windows Workflow Foundation is really all about... look no further than MSDN Virtual Labs!

From what I can tell, MS has set up some boxes with Virtual Server hosting images of pre-built machines containing various technology combinations. You use the web client to RDP to these machines, providing a reasonable remote control experience. You actually get administrator rights to the machine, allowing you freedom to try various things without being hampered by security. And I'm guessing that the machines are set up in undo mode and don't save state - so that the next person gets the same baseline machine as you started with. Cool!

In "ADO.Net 2 Advanced Data Access Patterns", Pablo Castro demonstrates the workings of an algebraic query processor, built on top of the ADO.Net technology. I guess it is technical, but his point is that it is possible, and actually not that difficult. I find it interesting to see the methods of logic processing that were presented in the advanced sessions this week - I've had to write some of these things before, but realize that I don't really understand the standard theories behind code and logic compilation. Good way to keep me humble!

One interesting thing that Pablo described was the indexing that happens behind the scenes in ADO.Net DataTables. If you run DataTable.Select, an index is automatically created on the data to optimize the select. Likewise, a DataView triggers the indexing - I suppose it is probably the same thing happening behind the scenes, but the DataView gives you a reference to the filter/sort request that was made, so that it is easy to re-execute it (though the creation of a new DataView with the same parameters would use the indexes created by the previous one)

I'm too young for this. A bunch of industry-leading language developers and university professors talking about dynamic languages with enough acronyms and language names to share a stick at! I have an interest in the progress of IronPython, so the title "Scripting and Dynamic Languages in the CLR" attracted my attention, especially seeing that Jim Hugunin was one of the panelists. They also had key members (perhaps leaders) of the Monad and VB projects from Microsoft, and a non-MS guy developing a language called Boo.

Questions were varied but there was this one statement that is worth remembering: "Computer Science is the one area where you can predict the future - just look back 20 years" - the theory being that 20 years ago men had these ideas, but only now do we have the horse-power to actually implement them. After all, most of the "cool new features" that we have spent the conference talking about are really old concepts that we are only now implementing, because the industry and technological capabilities are ripe for them. In reality, isn't it true at some level that nothing is really new - in many aspects we just keep repeating history on various levels.

This is almost unbelievable. I'm sitting in a session by Andres ("father" of C#) describing the future Language INtegrated Query implementation in C#. Here is the sample that he's dealing with (just to prove that the features go beyond just databsae queries)

var q =

from m in typeof(string).GetMethods()

where !m.IsStatic orderby mj.Name

group m by m.Name into g

select new {Method = g.Key, Overloads = g.Group.Count() };}

Lots of new stuff here to make this work - from the "var" feature to type inference based on a curly-braced list of values, to dynamic type extensions... Anyways, to say the least, I'm floored by the possibilities throughout the languages (C# and VB...) that this will provide. Next session is on C# 3 - I guess this will all make more sense then. Lots of new keywords, though... not sure if that is a good thing. But they are apparently all calls to methods behind the scenes, allowing full extensibility. Sounds almost scary!

    public string Message
    {
        get;
        set;
    }

    public void AddFile(string fileName) {}

    public void Send(string sendTo) {}

}

In hindsight, a few comments (and we'll see what the experts say...)

• A "From" property or argument may have been helpful, if we can't infer who the message is coming from
• We purposely ommitted CC, Subject, and BCC, because they weren't specifically requested in the requirements
• "To" is necessary in order to send, so we enforced that by making it part of the methods used to send the e-mail - could have made it a property with exception logic in the Send method, I suppose
• Tried to handle the simple case in a simple way, by providing static SendTo method
• Should probably deal with streams instead of just file names, but this provided a really simple way to handle attachments, and the goal was simplicity
• Once again, in order to provide simplicity we didn't handle multiple "To" strings - we could have used a collection or something, I suppose

Today's sessions of choice was "The Art of Building a Reusable Class Library" - Brad has posted so much about this that I just had to attend. One great thing about this session is that they gave away copies of their book "Framework Design Guidelines" to most attendees. It's great to have a session that walks through the important stuff, along with well-constructed, more detailed material to take home.

Brad took the floor for the first half of the morning, primarily talking about naming standards and why they were used. A few highlilghts:

• The Power of Sameness is key - do things the way that the developer would expect (this would apply to end-users of applications as well), and they are much less frustrated than if you do things the "right" way but not in the expected way. Sameness with existing standards or commonly-used components is key to this
• Along this line, "optimize globally" - sometimes you have to make your code "less good" in order for overall global consistency and to make it easier to understand from a standards perspective
• Be careful about overloading - overloading is great for providing "defaults", but all overloads must actually do the same thing - if methods are semantically different, use different method names
• Defaults provided by overloads, or defaults on properties, should used the "zeroed case". This way developers can make an intelligent guess as to what the default is. This requires that parameter and property names be appropriate to the default.
• Constructor arguments should be shortcuts for setting properties - many users think in terms of "dragging a component on" and then setting properties, so allowing a parameterless constructor with the ability to set instance properties is helpful to these developers, even though less concise

Krzysztof then walked through material geared more towards framework design overall:

• Keep it simple - frameworks naturally become more complex and it takes explicit effort to make them simple
• Best way to start is to write sample code the way you want developers to be able to write code against your framework - number of "new" statements in sample code is indication of complexity, since each may require that the user needs to discover a class
• There are attributes that can be used to control debugger layout (DebuggertypeProxy - cool!) and provide hints to Intellisense - use them
• CLS (Common Language Specification) os a cpmtract between framework designers and language designers - your framework must be CLS compliant in order to work with all .Net languages
• Prefer abstract classes (or just base classes) to interfaces, in order to support extensibility
• Projects to develop libraries should have an explicit API designer role

Brad offers some practical advice - a few highlights:

• don't make your consumers "archeologists" - leave artifacts that help developers understand the intent of your object model - make intent obvious
• Const/ReadOnly: readonly better than const if values might change
• Namespaces: use to organize classes, ensuring that the most-used classes are the most available, hiding the more advanced classes in sub-namespaces
• Classes:
  • ensure that they have a clear purpose - better to go overboard on classes named in a concrete fashion, rather than having too many abstract-named classes
  • think about what the developer will think the class does and whether this is obvious
  • once again, constructors should be used to capture state on instantiation - shouldn't do much work
• Enums:
  • the default numbers assigned to enum values actually do matter since calling assemblies use the number vs. the name
  • values should be specified explicitly in a framework assembly scenario
  • flags enum names should be plural
• Properties: use for cases when there is a "logical backing" for the property

Rocky spent some valuable time discussing n-tier and n-layer architectures.  A few memorable quotes:

"UI is expendable" - Avalon changes things again - you will have to re-write your UI to use it. Users always change their minds about UI - make it easy to change and keep business logic out of it

"Prevent code from leaking into the UI" - have, in some way, shape, or form, a Business Logic Layer that is separated from the UI

"Applications should be viewed as a set of layers" - nothing new really, but Rocky pushed distinction between tiers (implying network boundary) and layers, stipulating that layers provide code maintainability - you don't need tiers for this

And in terms of Visual Studio: "Object binding is at least as good as dataset binding - better because you have more control" - finally in .Net 2, business objects receive good UI design-time support

One attendee asked Rocky about MVC (Model/View/Controller pattern) - his answer was interesting. Rocky mentioned that MVC works for wizards and web programming, where there are specific sequences of interactions that the user needs to follow. In Windows applications, however, the user wants to have control, and a Controller tends to take the csontrol that the user should have. This jives with my limited exposure to MVC in windows applications - it tends to drive a multi-screen, somewhat modal user interface rather than the rich flexible "modeless" experience we have come to expect.

One thing I hadn't realized before was that you can inherit from a generic class with the type specified (for instance MyClass : List<int>). This is really handy in a business objects scenario where you want to deal with inherited collections.

This is cool. Over 100 desktops all running Windows Vista beta, connected to the internet, in the Windows Vista lab. I'm writing this blog entry from one of them. It is amazing the infrastructure that they have set up here - the expense and organization that they must have gone to!

Anyways, there are probably about 50 conference attendees playing around with Vista. I imagine that once the conference actually starts it will be hard to get time in the Internet Lab or the Vista areas, even with what must be thousands of connected machines in various parts of the conference center. Wow.

Rocky and Billy Hollis ran the morning part of their precon on ".Net Framework 2.0: The Smart Client Perspective". A few highlights:

They put in a strong push towards smart client applications, with processing on the client, vs. browser-based applications, in order to utilize the power of the client machine, retain more security control over data, etc.

Rocky spent some time going over new databinding features in .Net 2. Much of it I was already familiar with, but there were a few interesting comments:

- push of the new RAD development stuff as actually useful - Rocky was skeptical at first but is now convinced that Microsoft has done enough things right that the new auto-databinding functionality provides real value on real projects

- Microsoft finally produced a production-application-usable grid, the DataGridView, though there are a couple of things missing for real applications that can easily be remedied by creating your own descendant: Validation error handling on Esc or row change resets row without raising validation events on dataset.

- DataTables are now paired with DataAdapters right in the DataSet definition, with partial class support making them usable as business objects

- With partial classes, you can add interface implementations (so that you can add a level of standardization to implementations of partial classes)

- Naming standards for controls are affected by defaults that MS provides - when you drag data elements from the data sources window onto a form, the resultant controls are named according to a new naming scheme <name of property><name of control> (e.g. NameTextBox, NameLabel...) vs. traditional hungarian standard (txtName, lblName). Rocky actually uses the new standard now in his own development (tough to break old habits, he says...)