Category Archives: Software Architecture

Software Design Pattern Quick Reference

1
Posted by admin on September 27, 2010 – 8:54 pm
Filed under Software Architecture, VB Feng Shui

I’m a somewhat reluctant believer in software design patterns. On the one hand, it can be handy to have a lingua franco to discuss common patterns with. On the other, the concept has seemed to me to be so wildly hyped over the past few years, that you’d think it was the brand new answer to everything.

Truth is, I’m guessing most every programmer who’s been working for any length of time recognizes most of the common patterns, and has applied them innumerable times over the years.

Still, I’ve never spent much time truly digging into the meat and potatoes of each pattern.

Then I came across Jason McDonald’s Design Pattern Quick Reference PDF here.

image

To the right is a reduced view of one of the pages.

Really well done reference sheets for those that want to put the names with the patterns they likely already know quite well.

Highly recommended!

Cleaning up Messy DataContractSerializer XML

5
Posted by admin on March 6, 2010 – 6:16 am
Filed under Code Garage, Software Architecture, VB Feng Shui, XML

I was working with XML serialization of objects recently and was using the good ol’ DataContractSerializer again.

One thing that I bumped into almost immediately is that the XML that it spits out isn’t exactly the neatest, tidiest of XML possible, to say the least.

So I set out on a little odyssey to see exactly how nice and clean I could make it.

(EDIT: I’ve added more information about how the Name property of the Field object is being serialized twice, which is another big reason for customizing the serialization here, and for specialized dictionary serialization in general).

First, the objects to serialize. I’ve constructed a very rudimentary object hierarchy that still illustrates the problem well.

In this case, I have a List of Record objects, called a Records list. Each Record object is a dictionary of Field objects. And each Field object contains two properties, Name and Value. The code for these (and a little extra code to make populating them easy) is as follows.

Public Class Records
    Inherits List(Of Record)


    Public Sub New()
        '---- default constructor
    End Sub

End Class


Public Class Record
    Inherits Dictionary(Of String, Field)


    Public Sub New()
        '---- default constructor
    End Sub


    Public Sub New(ByVal ParamArray Fields() As Field)
        For Each f In Fields
            Me.Add(f.Name, f)
        Next
    End Sub
End Class


Public Class Field

    Public Sub New()
        '---- default constructor
    End Sub


    Public Sub New(ByVal Name As String, ByVal Value As String)
        Me.Name = Name
        Me.Value = Value
    End Sub


    Public Property Name() As String
        Get
            Return _Name
        End Get
        Set(ByVal value As String)
            _Name = value
        End Set
    End Property
    Private _Name As String



    Public Property Value() As String
        Get
            Return _Value
        End Get
        Set(ByVal value As String)
            _Value = value
        End Set
    End Property
    Private _Value As String

End Class

Yes, I realize there are DataTables, KeyValuePair objects, etc that could do this, but that’s not the point, so just bear with me<g>.

To populate a Records object, you might have code that looks like this:

Dim Recs = New Records
Recs.Add(New Record(New Field("Name", "Darin"), New Field("City", "Arlington")))
Recs.Add(New Record(New Field("Name", "Gillian"), New Field("City", "Ft Worth")))
Recs.Add(New Record(New Field("Name", "Laura"), New Field("City", "Dallas")))

Ok, so far so good.

Now, lets serialize that with a simple serialization function using the DataContractSerializer:

    ''' <summary>
    ''' Serializes the data contract to a string (XML)
    ''' </summary>
    Public Function Serialize(Of T As Class)(ByVal SerializeWhat As T) As String
        Dim stream = New System.IO.StringWriter
        Dim writer = System.Xml.XmlWriter.Create(stream)

        Dim serializer = New System.Runtime.Serialization.DataContractSerializer(GetType(T))
        serializer.WriteObject(writer, SerializeWhat)
        writer.Flush()

        Return stream.ToString
    End Function

In the test application, I put together, I dump the resulting XML to a text box. Yikes!

image

So, what’re the problems here? <g>

  1. You’ve got that “http://www.w3.org/2001/XMLSchema-instance” namespace attribute amongst other
  2. lots of random letters
  3. no indenting
  4. You can’t really tell it from this shot, but the Record dictionary is serializing the name property twice, because I’m using it as the Key for the dictionary, but it’s also a property of the objects in the dictionary.

All this noise might be fine for computer to computer communication, but it’s pretty tough on human eyes<g>.

Ok, first thing to do is indent:

    ''' <summary>
    ''' Serializes the data contract to a string (XML)
    ''' </summary>
    Public Function Serialize(Of T As Class)(ByVal SerializeWhat As T) As String
        Dim stream = New System.IO.StringWriter
        Dim xmlsettings = New Xml.XmlWriterSettings
        xmlsettings.Indent = True
        Dim writer = System.Xml.XmlWriter.Create(stream, xmlsettings)

        Dim serializer = New System.Runtime.Serialization.DataContractSerializer(GetType(T))
        serializer.WriteObject(writer, SerializeWhat)
        writer.Flush()

        Return stream.ToString
    End Function

Notice that I added the use of the XMLWriterSettings object. This allows me to set the Indent property, and things are much more readable.

image

But that’s still a far cry from nice, simple, tidy XML. Notice all the “ArrayofArrayOf blah blah” names, and the randomized letter sequences? Plus, it’s much more obvious how the NAME jproperty is being serialized twice now. Yuck! Surely, we can do better than this!

Cleaning Up the Single Entity Field Object

The DataContractSerializer certainly works easily enough to serialize the Field object, but unfortunately, it decorates the serialized elements with a load of really nasty looking and completely unnecessary cruft.

My first thought was to simply decorate the class with <DataContract> attributes:

<DataContract(Name:="Field", Namespace:="")> _
Public Class Field

    Public Sub New()
        '---- default constructor
    End Sub


    Public Sub New(ByVal Name As String, ByVal Value As String)
        Me.Name = Name
        Me.Value = Value
    End Sub

    <DataMember()> _
    Public Property Name() As String
        Get
            Return _Name
        End Get
        Set(ByVal value As String)
            _Name = value
        End Set
    End Property
    Private _Name As String



    <DataMember()> _
    Public Property Value() As String
        Get
            Return _Value
        End Get
        Set(ByVal value As String)
            _Value = value
        End Set
    End Property
    Private _Value As String

End Class

But this yields:

image

So we have several problems:

  • Each field is rendered into a Value element of the Record’s field collection
  • The Key of the Record collection duplicates the Name of the individual Field objects
  • and we still have a noxious xmlns=”” attribute being rendered.

Unfortunately, this is where the DataContractSerializer’s simplicity is it’s downfall. There’s just no way to customize this any further, using ONLY the DataContractSerializer.

However, we can implement IXMLSerializable on our Field object to customize its serialization. All I need to do is remove the DataContract attribute, and add a simple implementation of IXMLSerializable to the class:

Public Class Field
    Implements System.Xml.Serialization.IXmlSerializable


    Public Sub New()
        '---- default constructor
    End Sub


    Public Sub New(ByVal Name As String, ByVal Value As String)
        Me.Name = Name
        Me.Value = Value
    End Sub

    Public Property Name() As String
        Get
            Return _Name
        End Get
        Set(ByVal value As String)
            _Name = value
        End Set
    End Property
    Private _Name As String


    Public Property Value() As String
        Get
            Return _Value
        End Get
        Set(ByVal value As String)
            _Value = value
        End Set
    End Property
    Private _Value As String


    Public Function GetSchema() As System.Xml.Schema.XmlSchema Implements System.Xml.Serialization.IXmlSerializable.GetSchema
        Return Nothing
    End Function


    Public Sub ReadXml(ByVal reader As System.Xml.XmlReader) Implements System.Xml.Serialization.IXmlSerializable.ReadXml

    End Sub


    Public Sub WriteXml(ByVal writer As System.Xml.XmlWriter) Implements System.Xml.Serialization.IXmlSerializable.WriteXml
        writer.WriteElementString("Name", Me.Name)
        writer.WriteElementString("Value", Me.Value)
    End Sub
End Class

And that yields a serialization of:

image

Definitely better, but still not great.

Cleaning up a Generic Dictionary’s Serialization

The problem now is with the Record dictionary.

Public Class Record
    Inherits Dictionary(Of String, Field)
    Implements System.Xml.Serialization.IXmlSerializable


    Public Sub New()
        '---- default constructor
    End Sub


    Public Sub New(ByVal ParamArray Fields() As Field)
        For Each f In Fields
            Me.Add(f.Name, f)
        Next
    End Sub

    Public Function GetSchema() As System.Xml.Schema.XmlSchema Implements System.Xml.Serialization.IXmlSerializable.GetSchema
        Return Nothing
    End Function

    Public Sub ReadXml(ByVal reader As System.Xml.XmlReader) Implements System.Xml.Serialization.IXmlSerializable.ReadXml

    End Sub

    Public Sub WriteXml(ByVal writer As System.Xml.XmlWriter) Implements System.Xml.Serialization.IXmlSerializable.WriteXml
        For Each f In Me.Values
            DirectCast(f, System.Xml.Serialization.IXmlSerializable).WriteXml(writer)
        Next
    End Sub
End Class

Adding an IXMLSerializable implementation to it as well yields the following XML:

image

Definitely much better! Especially notice that we’ve gotten rid of the duplicated “Name” key. It was duplicated before because we used the Name element of the Field object as the Key for the Record dictionary. This be play an important part in deserializing the Record’s dictionary of Field objects later.

Cleaning up the List of Records

Finally, the only thing really left to do is clean up how the generic list of Record objects is serialized.

But once again, the only way to alter the serialization is to implement IXMLSerializable on the class.

<Xml.Serialization.XmlRoot(Namespace:="")> _
Public Class Records
    Inherits List(Of Record)
    Implements System.Xml.Serialization.IXmlSerializable


    Public Sub New()
        '---- default constructor
    End Sub

    Public Function GetSchema() As System.Xml.Schema.XmlSchema Implements System.Xml.Serialization.IXmlSerializable.GetSchema
        Return Nothing
    End Function

    Public Sub ReadXml(ByVal reader As System.Xml.XmlReader) Implements System.Xml.Serialization.IXmlSerializable.ReadXml

    End Sub

    Public Sub WriteXml(ByVal writer As System.Xml.XmlWriter) Implements System.Xml.Serialization.IXmlSerializable.WriteXml
        For Each r In Me
            DirectCast(r, System.Xml.Serialization.IXmlSerializable).WriteXml(writer)
        Next
    End Sub
End Class

Notice that I’ve implemented IXMLSerializable, but I also added the XmlRoot attribute with a blank Namespace parameter. This completely clears the Namespace declaration from the resulting output, which now looks like this:

image

And that is just about as clean as your going to get!

But That’s Not all there is To It

Unfortunately, it’s not quite this simple. The thing is, you very well may want to serialize each object independently, not just serialize the Records collection. Doing that as we have things defined right now won’t work. The Start and End elements won’t be generated in the XML properly.

Instead, we need to add XmlRoot attributes to all three classes, and adjust where the WriteStartElement and WriteEndElement calls are made. So we end up with this:

<Xml.Serialization.XmlRoot(Namespace:="")> _
Public Class Records
    Inherits List(Of Record)
    Implements System.Xml.Serialization.IXmlSerializable


    Public Sub New()
        '---- default constructor
    End Sub

    Public Function GetSchema() As System.Xml.Schema.XmlSchema Implements System.Xml.Serialization.IXmlSerializable.GetSchema
        Return Nothing
    End Function

    Public Sub ReadXml(ByVal reader As System.Xml.XmlReader) Implements System.Xml.Serialization.IXmlSerializable.ReadXml

    End Sub

    Public Sub WriteXml(ByVal writer As System.Xml.XmlWriter) Implements System.Xml.Serialization.IXmlSerializable.WriteXml
        For Each r In Me
            writer.WriteStartElement("Record")
            DirectCast(r, System.Xml.Serialization.IXmlSerializable).WriteXml(writer)
            writer.WriteEndElement()
        Next
    End Sub
End Class


<Xml.Serialization.XmlRoot(ElementName:="Record", Namespace:="")> _
Public Class Record
    Inherits Dictionary(Of String, Field)
    Implements System.Xml.Serialization.IXmlSerializable


    Public Sub New()
        '---- default constructor
    End Sub


    Public Sub New(ByVal ParamArray Fields() As Field)
        For Each f In Fields
            Me.Add(f.Name, f)
        Next
    End Sub

    Public Function GetSchema() As System.Xml.Schema.XmlSchema Implements System.Xml.Serialization.IXmlSerializable.GetSchema
        Return Nothing
    End Function

    Public Sub ReadXml(ByVal reader As System.Xml.XmlReader) Implements System.Xml.Serialization.IXmlSerializable.ReadXml

    End Sub

    Public Sub WriteXml(ByVal writer As System.Xml.XmlWriter) Implements System.Xml.Serialization.IXmlSerializable.WriteXml
        For Each f In Me.Values
            writer.WriteStartElement("Field")
            DirectCast(f, System.Xml.Serialization.IXmlSerializable).WriteXml(writer)
            writer.WriteEndElement()
        Next
    End Sub
End Class


<Xml.Serialization.XmlRoot(ElementName:="Field", Namespace:="")> _
Public Class Field
    Implements System.Xml.Serialization.IXmlSerializable


    Public Sub New()
        '---- default constructor
    End Sub


    Public Sub New(ByVal Name As String, ByVal Value As String)
        Me.Name = Name
        Me.Value = Value
    End Sub

    Public Property Name() As String
        Get
            Return _Name
        End Get
        Set(ByVal value As String)
            _Name = value
        End Set
    End Property
    Private _Name As String


    Public Property Value() As String
        Get
            Return _Value
        End Get
        Set(ByVal value As String)
            _Value = value
        End Set
    End Property
    Private _Value As String


    Public Function GetSchema() As System.Xml.Schema.XmlSchema Implements System.Xml.Serialization.IXmlSerializable.GetSchema
        Return Nothing
    End Function


    Public Sub ReadXml(ByVal reader As System.Xml.XmlReader) Implements System.Xml.Serialization.IXmlSerializable.ReadXml

    End Sub


    Public Sub WriteXml(ByVal writer As System.Xml.XmlWriter) Implements System.Xml.Serialization.IXmlSerializable.WriteXml
        writer.WriteElementString("Name", Me.Name)
        writer.WriteElementString("Value", Me.Value)
    End Sub
End Class

 
 

And Finally, Deserialization

Of course, all this would be for nought if we couldn’t actually deserialize the xml we’ve just spent all this effort to clean up.

Turns out that deserialization is pretty straightforward. I just needed to add code to the ReadXml member of the implemented IXMLSerializable interface. The full code for my testing form is below. Be sure to add a reference to System.Runtime.Serialization, though, or you’ll have type not defined errors. 

Public Class frmSample

    Private Sub btnTest_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles btnTest.Click

        '---- populate the objects
        Dim Recs = New Records
        Recs.Add(New Record(New Field("Name", "Darin"), New Field("City", "Arlington")))
        Recs.Add(New Record(New Field("Name", "Gillian"), New Field("City", "Ft Worth")))
        Recs.Add(New Record(New Field("Name", "Laura"), New Field("City", "Dallas")))

        Dim t As String
        t = Serialize(Of Field)(Recs(0).Values(0))
        Dim fld = Deserialize(Of Field)(t)
        Debug.Print(fld.Name)
        Debug.Print(fld.Value)
        Debug.Print("--------------")

        t = Serialize(Of Record)(Recs(0))
        Dim rec = Deserialize(Of Record)(t)
        Debug.Print(rec.Values.Count)
        Debug.Print("--------------")

        t = Serialize(Of Records)(Recs)
        tbxOutput.Text = t

        Dim recs2 = Deserialize(Of Records)(t)
        Debug.Print(recs2.Count)
    End Sub
End Class


<Xml.Serialization.XmlRoot(Namespace:="")> _
Public Class Records
    Inherits List(Of Record)
    Implements System.Xml.Serialization.IXmlSerializable


    Public Sub New()
        '---- default constructor
    End Sub

    Public Function GetSchema() As System.Xml.Schema.XmlSchema Implements System.Xml.Serialization.IXmlSerializable.GetSchema
        Return Nothing
    End Function

    Public Sub ReadXml(ByVal reader As System.Xml.XmlReader) Implements System.Xml.Serialization.IXmlSerializable.ReadXml
        reader.MoveToContent()
        reader.ReadStartElement("Records")
        reader.MoveToContent()
        Do While reader.NodeType <> Xml.XmlNodeType.EndElement
            Dim Rec = New Record
            DirectCast(Rec, System.Xml.Serialization.IXmlSerializable).ReadXml(reader)
            Me.Add(Rec)
            reader.MoveToContent()
        Loop
        reader.ReadEndElement()
    End Sub

    Public Sub WriteXml(ByVal writer As System.Xml.XmlWriter) Implements System.Xml.Serialization.IXmlSerializable.WriteXml
        For Each r In Me
            writer.WriteStartElement("Record")
            DirectCast(r, System.Xml.Serialization.IXmlSerializable).WriteXml(writer)
            writer.WriteEndElement()
        Next
    End Sub
End Class


<Xml.Serialization.XmlRoot(ElementName:="Record", Namespace:="")> _
Public Class Record
    Inherits Dictionary(Of String, Field)
    Implements System.Xml.Serialization.IXmlSerializable


    Public Sub New()
        '---- default constructor
    End Sub


    Public Sub New(ByVal ParamArray Fields() As Field)
        For Each f In Fields
            Me.Add(f.Name, f)
        Next
    End Sub

    Public Function GetSchema() As System.Xml.Schema.XmlSchema Implements System.Xml.Serialization.IXmlSerializable.GetSchema
        Return Nothing
    End Function

    Public Sub ReadXml(ByVal reader As System.Xml.XmlReader) Implements System.Xml.Serialization.IXmlSerializable.ReadXml
        reader.MoveToContent()
        reader.ReadStartElement("Record")
        reader.MoveToContent()
        Do While reader.NodeType <> Xml.XmlNodeType.EndElement
            Dim fld = New Field
            DirectCast(fld, System.Xml.Serialization.IXmlSerializable).ReadXml(reader)
            Me.Add(fld.Name, fld)
            reader.MoveToContent()
        Loop
        reader.ReadEndElement()
    End Sub

    Public Sub WriteXml(ByVal writer As System.Xml.XmlWriter) Implements System.Xml.Serialization.IXmlSerializable.WriteXml
        For Each f In Me.Values
            writer.WriteStartElement("Field")
            DirectCast(f, System.Xml.Serialization.IXmlSerializable).WriteXml(writer)
            writer.WriteEndElement()
        Next
    End Sub
End Class


<Xml.Serialization.XmlRoot(ElementName:="Field", Namespace:="")> _
Public Class Field
    Implements System.Xml.Serialization.IXmlSerializable


    Public Sub New()
        '---- default constructor
    End Sub


    Public Sub New(ByVal Name As String, ByVal Value As String)
        Me.Name = Name
        Me.Value = Value
    End Sub

    Public Property Name() As String
        Get
            Return _Name
        End Get
        Set(ByVal value As String)
            _Name = value
        End Set
    End Property
    Private _Name As String


    Public Property Value() As String
        Get
            Return _Value
        End Get
        Set(ByVal value As String)
            _Value = value
        End Set
    End Property
    Private _Value As String


    Public Function GetSchema() As System.Xml.Schema.XmlSchema Implements System.Xml.Serialization.IXmlSerializable.GetSchema
        Return Nothing
    End Function


    Public Sub ReadXml(ByVal reader As System.Xml.XmlReader) Implements System.Xml.Serialization.IXmlSerializable.ReadXml
        reader.MoveToContent()
        reader.ReadStartElement("Field")
        reader.MoveToContent()
        If reader.Name = "Name" Then Me.Name = reader.ReadElementContentAsString
        reader.MoveToContent()
        If reader.Name = "Value" Then Me.Value = reader.ReadElementContentAsString
        reader.MoveToContent()
        reader.ReadEndElement()
    End Sub


    Public Sub WriteXml(ByVal writer As System.Xml.XmlWriter) Implements System.Xml.Serialization.IXmlSerializable.WriteXml
        writer.WriteElementString("Name", Me.Name)
        writer.WriteElementString("Value", Me.Value)
    End Sub
End Class



Public Module Serialize
    ''' <summary>
    ''' Serializes the data contract to a string (XML)
    ''' </summary>
    Public Function Serialize(Of T As Class)(ByVal SerializeWhat As T) As String
        Dim stream = New System.IO.StringWriter
        Dim xmlsettings = New Xml.XmlWriterSettings
        xmlsettings.Indent = True
        Dim writer = System.Xml.XmlWriter.Create(stream, xmlsettings)

        Dim serializer = New System.Runtime.Serialization.DataContractSerializer(GetType(T))
        serializer.WriteObject(writer, SerializeWhat)
        writer.Flush()

        Return stream.ToString
    End Function


    ''' <summary>
    ''' Deserializes the data contract from xml.
    ''' </summary>
    Public Function Deserialize(Of T As Class)(ByVal xml As String) As T
        Using stream As New MemoryStream(UnicodeEncoding.Unicode.GetBytes(xml))
            Return DeserializeFromStream(Of T)(stream)
        End Using
    End Function


    ''' <summary>
    ''' Deserializes the data contract from a stream.
    ''' </summary>
    Public Function DeserializeFromStream(Of T As Class)(ByVal stream As Stream) As T
        Dim serializer As New DataContractSerializer(GetType(T))
        Return DirectCast(serializer.ReadObject(stream), T)
    End Function
End Module

Of particular note above is the ReadXML function of the Field object.

It checks the name of the node first and then places the value of the node into the appropriate property of that object. If I didn’t do that, the deserialization process would require the fields in the XML to be in a specific order. This is a minor drawback to the DataContractSerializer that this approach alleviates.

What’s Next?

The one unfortunate aspect of this is that it requires you to implement IXMLSerializable on each object that you want the XML cleaned up for.

Generally speaking, The DataContractSerializer will be perfectly fine for those cases where humans aren’t likely to ever have to see the XML you’re generating. And you get a performance boost for sacrificing that flexibility and “cleanliness”.

But for things like data file imports, custom configuration files, and the like, it may be desirable to  implement custom serialization like this so that your xml files can be almost as easy to read as those old school INI files!

Public Interfaces

0
Posted by admin on November 17, 2007 – 4:30 am
Filed under Rants, Software Architecture, VB Feng Shui

image I’m guessing that the vast majority of VB apps (VB6, or .NET), have no public interface. After all, VB is the prototyping language, not an actual project development language, right? </sarcasm>

Well, if you do eventually find yourself in need of exposing a public interface from your application, what’s the right way to do it?

First, a definition, though.

By public interface, I’m talking about some manner of exposing functionality within your application to the outside world. What you do with your BAS files, and private CLS files, not to mention FRM’s, or the all-encompassing  VB.NET *.VB file is your own business. But what the world sees, or, more appropriately, has to deal with, is another matter altogether.

There’s a pile o’ ways to expose functionality from an app, especially a VB app.

First, a few old school methods….

  • DDE – Yeah, it’s still alive. Want proof? Just boot up a copy of Vista, load REGEDIT and search for DDEEXEC in the HKCR hive. But seriously, you don’t want to go there.
  • Windows Messages – SendMessage/PostMessage. They’re not just for subclassing and peeping toms. DDE and even COM relies on the Window Messaging subsystem to work. Your apps can leverage it too. But really, that’s a whole lot of pain for not a lot of gain, so why bother?
  • DLL Entry Points – There are several tools out there that make exposing DLL entry points from a VB application relatively easy to do. In some cases, this is how you have to expose functionality (as in when some other app only makes calls to DLL entry points, and you want that app to talk to yours). But using this technique to expose your own functionality to the world just seems so, well, reagan-omic.

And the more common techniques….

  • COM – The classic VB PUBLIC class. All you gotta do is change your class’s interface type to PUBLICNOTCREATABLE, MULTIUSE, or GLOBALMULTIUSE and biff boom pow! Anyone can use your class, right?
  • .NET Assemblies – Same as COM, but shinier

OK, COM (or .NET assemblies) it is (I’m going to consider the two the same for now, what sacrilege!)

So how do you do it?

There’s piles of books on the mechanics of the task, so I’m not going there. Just look at Kurata’s Doing Objects in Visual Basic 2005 or Dan Appleman’s various books on ActiveX techniques for those kinds of details.

What I’m talking about is which interface design is most appropriate.

Kinds of Interfaces

Generally, I’ve seen these designs gather into 3 camps:

  • The massive wad of hierarchically related objects. This is the Outlook, Word or Excel object models.
  • The single public class containing all the functions you could ever want. Not terribly common; I see it most is 3’rd party utility libraries.
  • And finally, the single class with a single (or at most very limited set of) functions that serve as a “command line” of sorts where you might pass in a parameter that is the “operation” and that additional parameters that are the “arguments for the operation”. The GroupWise API is a great example of this.

The Massive Hierarchical Wad

Pros

  • Easiest to program against. Intellisense, separate objects, etc speed working with your model.

Cons

  • Hardest to keep compatible. Even minor changes from one version to the next of your application can render it incompatible with previous versions of your application, causing loads of headaches for your users.

The Single Class

Pros

  • Relatively easy to program against. Intellisense will help. So does consistent naming of all those methods and properties.
  • Works well for relatively minor amounts of exposed functionality.

Cons

  • Generally considered bad practice.
  • Suffers from compatibility headaches much like the Massive Wad.

The Command Line Class

Pros

  • Essentially immune from direct interface compatibility issues, since the lone interface is flexible enough initially to never have to be changed.

Cons

  • More difficult to code against. Intellisense only helps with the command line function itself, not with each of the commands that can be sent.
  • Moves compatibility issues to the user. If new functions are introduced, it’s the users responsibility to test for the version of the application and react appropriately.

So, what’s the final word?

As usual, there’s really no right answer.

Personally, I tend to stay away from the “Single Class”, simply because it has all the difficulties associated with the Massive Wad, and none of the immunity of the Command Line Class; the worst of both worlds.

The Command Line Class is most useful when your exposed function points number in the 10-100’s. Any more than that, and it starts to become unwieldy, though it’s still perfectly workable.

The Massive Wad is the most traditional, most familiar style of public interface to those who’ve likely used public interfaces of other systems. That’s not to say it’s the best option, just that’s it’s the most typical.

How about it? What kinds of public interfaces have you built and put out there? Is there a style I’ve missed. Maybe something better than any of these?

Reimagining MsgBox

0
Posted by admin on November 15, 2007 – 4:03 am
Filed under Code Garage, Software Architecture, VB Feng Shui

Here’s a little trick I’m not sure many people know about, but that I’ve used for so long, I’d basically forgotten about it.

I wrote about overriding the ERR object in VB here, and also wrote a far more involved article about it.

But did you know you can also override the MSGBOX function?

Just create a function with the following signature in a BAS module of your choice:

Public Function MsgBox(ByVal Prompt$, Optional ByVal Buttons As VbMsgBoxStyle = vbOKOnly, Optional ByVal Title$ = "", Optional ByVal HelpFile$ = "", Optional ByVal Context As Long = 0) As VbMsgBoxResult

Put the appropriate code in it, and presto, custom msgbox.

Why, you might ask?

  • Personally, I like the option of logging every msgbox that’s displayed by my app. Errs are handier, but msgbox’s can be useful.
  • In addition, you have the option of calling the MessageBox API call directly yourself, which gives you access to additional flags that you can’t use with the VB version alone.
  • You might also decide that the MSGBOX proper just doesn’t look good, and craft up a modal, nicely skinned form to stand in its place.
  • And finally, in a particular app I worked on, I needed to call a function BEFORE and a different function AFTER displaying every msgbox. I certainly didn’t want to alter every call to MSGBOX and add those extra lines. Overriding it made that a trivial task.

Please let me know if you come up with any good uses for this trick.

Online Apps, Good or Bad?

5
Posted by admin on August 21, 2007 – 10:10 pm
Filed under Rants, Software Architecture

John Dvorak wrote a very interesting article for PCMag on 8/14, Google Pulls Plug, Everyone Misses Point.

I’ve been saying web apps were overhyped ever since SalesForce first came out and was getting tons of hype back in the 90’s, and that’s not because I used to work at a competitor (gotta love the wayback machine).

On the surface, it’s a great idea. No installation. No deployment headaches. No massive, multi machine upgrade pains. And with AJAX, and now SilverLight, you can get a user experience approaching a traditional fat client. Plus, with broadband nearing ubiquity, some of the bandwidth issues of the past are no more.

And for many installations, where users can connect to a centralized server within the company’s domain, it often is a very smart architecture.

So what’s the problem?

Dvorak points to the demise of the Google DTO/DTR program as exactly the problem. Imagine if it was YOUR BUSINESS that was running off the DTO program and Google pulled the plug. “Oh, you won’t be able to access your customer records after Aug 8th, but here’s a coupon for 2 bucks at Google Checkout you can use for the next 2 months.”

I doubt SalesForce is going anywhere anytime soon, and they do have a compelling product. I’m not even picking on them, per se. But the whole idea of putting that kind of trust into an app that’s running completely NOT under your control is just a little, eh, bothersome?

In fact, I tend to believe that the absolute BEST thing that could happen for everyone is for a few more biggies, like Google Apps, or SalesForce, or Microsoft MSN Mail, etc, to bite the dust and strand millions of people.

It’d hurt, but people would take a serious look at the implications of relying on ASPs to supply services like that.

There were some big reasons back in the early 80’s that the personal computer and the fat client app, as opposed to the mainframe and the dumb terminal, because so popular. Some of them have been forgotten, and unfortunately, it might take a few tough lessons to remind people.

They Killed the Web! The Bastards!

1
Posted by admin on August 17, 2007 – 4:14 am
Filed under Software Architecture, VB Feng Shui

The web as we know it is in its death throws.

Um, right.

I just read the Guest Opinion in the latest Visual Studio Magazine. It’s by Rockford Lhotka, who I have a lot of respect for. But this piece was a little off.

He basically claims that “the web as we know it is finally coming to an end”. Why, you may ask?

  • Is it the impending rollout of IPV6?
  • Maybe some new 3d “navigator” (as in the-chess-set-on-the-millenium-falcon 3d, not yet-another-2d-window-into-a-virtual-3d-space 3d)?
  • Or maybe there’s a new “brain driven” interface I hadn’t heard of?

No.

It’s Silverlight. and Atlas.

Sigh.

According to Rockford, AJAX is the “last gasp of a dying technology”. He argues that at some point, “either the browser transforms into a full blown programming platform or we find another answer”, and that answer, apparently is SilverLight.

Now, don’t get me wrong. SilverLight is pretty slick, as long as you don’t try to find any examples of actual web apps written in it. You know, the kind that people would use as opposed to just play with for 5 seconds. There’s tons of nice animated displays synched to music and pretty graphics of pages flipping, but where’s the data driven samples, or the reporting grids, or the company dashboards, etc?

Not only that, but hasn’t the web already got a “launch point to load something that is a programming platform”. I thought it was called Flash? And flash has certainly not brought the end of the Web nigh. Hell, it’s harder and harder to find sites that even bother with it anymore.

And SilverLight is from Microsoft, so you can bet that, even if they initially support a plethora of browsers and systems, eventually, it’ll get whittled down to Windows Voyeur (or whatever they’ll be calling the new version in 5 years).

Rockford makes a good point about technologies lasting upwards of around 10 years before being replaced by newer, better concepts. Things like COM, Win32, and CORBA. Things like ISA, the serial and parallel port, and ATA IDE. Things like hard drives, mice, qwerty keyboards, text files and relational DBMSs…. Oh wait.

I’d lay money that the next “big thing,” the thing that “kills the web as we know it” and ushers in a new era similar to the internet age of the 90’s, will not come from a big house like Microsoft, or IBM, or even Xerox. It’ll come from some dedicated hacker like Marc Andreeson or Bram Cohen. It’ll start off small. Hardly anyone will use it, kinda like Google back in, oh, 1999. And it’ll probably have a goofy name, nothing as cleanly futuristic as “SilverLight”.

Until then, I’d say the odds are long on HTML, Javascript, Ajax, etc, going poof.

One Big Control or Lots of Little Ones

3
Posted by admin on August 10, 2007 – 12:23 pm
Filed under ASP, Software Architecture

I’ve been delving into ASP.NET programming lately and one thing that immediately struck me as odd is just how many controls end up on an ASP page.

A typical data entry page consists of, generally, lots of labels and textboxes, a few option buttons or check boxes, even fewer combo boxes and list boxes, a grid maybe, and few buttons (buttons, links, whatever they happen to look like).

Granted, depending on the application, you may have a few particular screens that are more complicated (say, a scheduling screen), but by and large, for general data input, that about sums it up.

But when I look at what’s involved in ASP.NET to make that happen, it’s almost mind boggling.

Of course, you have a label control for a particular field, you have the field itself, but then you have separate validator controls for each kind of validation you might want to perform. Add in tables to get things to line up nicely

To me, it seems much more logical to have one “data input” control, that can handle all (or rather the most common) data entry tasks via properties.

Want a caption above the input box, rather than to the left of it; set a property. Want the text to be validated a alpha numeric, but only including A-F, and it must be > 4 chars, less than 10, blah blah; set a property (or two). What this field to be a choice between True/False; set a property to make it a radio button group, a list, or a drop down combo box.

Ages ago, there was a UI package called SmartUI. Looks like it’s now sold by Xceed. No idea whether it’s any good now. It was ok back then, although it had it’s share of issues. But I always thought the idea was right. One control that could do all sorts of the most common data input type tasks, just by dropping it on a form and setting a few properties.

I completely understand the idea of “modularizing” functionality and the ASP control model definitely does that.

So my question is, is that the best way?

All those controls eventually just render HTML anyway, so is there a penalty for one big control vs lots of little ones rendering that html?

Does it make the page easier for the user to work with?

Do separate little controls make it easier for the developer?

Microsoft used to say that INI files were the absolute best way to store your application settings. Then it became the registry, and INI files were passe. Now, it’s back to INI files…albeit with a lot more tag stuff, funny angle brackets and often terrible formatting…oh, right, I mean XML files.

My point is, I’m not one to just accept Microsoft’s take on a topic, no matter how much framework they’ve thrown at it. 

And I’m wondering if their control model might be another one of those reasons to break with the pack.

VB8 to have Runtime Agility

1
Posted by admin on June 29, 2007 – 2:14 am
Filed under Software Architecture, VB Feng Shui

Leave it to MS to come up with the phrase Runtime Agility, but the concept, if I’m understanding it right, is very intriguing.


The post is here, but to summarize, Paul Vick is a lead on the VB team, and is discussing some of the items on the block for VB8.


He off hand mentions this…


“Runtime agility. The ability to compile without a VB runtime, or targeting another VB runtime.”


Now, if I’m reading that right, this would seem to be huge. The idea of VB being able to “compile in” the runtime is something I know I’ve been asking for since VB3. Does it waste a little space? Sure. But it means you can truly have a single EXE “copy and deploy” type scenario.


And does this mean the .NET runtime bits that are necessary will get baked in as well? Too early to tell, I suppose. Still. Something very interesting to watch in the coming months.

The VS Shell and Extension Methods

5
Posted by admin on June 24, 2007 – 3:33 am
Filed under Software Architecture, VB Feng Shui

Here’s an interesting read on something coming down the pike with Visual Studio. Basically, it’s a customizable shell of VS that would theoretically allow you to build you’re own Visual Studio, language and all.


Likely, it’ll be on a complexity scale of integrating VBA into your app (anyone remember that 300-armed, greased-up monster squid?), but still, very interesting.


Another interesting read on Extension Methods coming in VB9. I’ve wondered why something like this hasn’t been in VB since the very early days of classes (anyone remember VB4?). Why, oh, why have I never been able to create a method like:

Public Function MyOwnReplace(Self as string, Arg as string) as String Extends String

      Return Blah(Arg)

End Function

and then use it by calling the function method off of any ol’ string variable…

Debug.Print MyString.MyOwnReplace(Arg)

Maybe this is a contrived example, but the Dynamic languages concept of extending existing objects is something that just belongs in VB.


 

PowerShell Curiosities

2
Posted by admin on June 15, 2007 – 7:07 pm
Filed under Software Architecture, Utilities

I’ve recently read several blogs about how great Windows PowerShell is, so I decided to check it out myself last night.

I didn’t get very far before I came across this on the download page:

“The .NET Framework 2.0 is required in order to install Windows PowerShell”

Ok, fair enough.

And then I proceeded to actually check out the download page, where they present no fewer than 20 different download options, including variants for “English” and “localized”, x86 and x64, plus Itanium.

First, I know from experience that it would be almost insane to suggest that small development shops try to maintain 20 different downloads of what is essentially the same product. MS can get away with this because they’ve got lots of money to throw at the problem, but is 20 different downloads of a command shell utility really justified? Ok, some of them are for some MultiLingual UI addon, so the total versions of the utility iself is fewer than that, but not by much.

The bigger issue I have here, though, is that I thought, and MS would surely have everyone believe, that the .NET runtime and the JIT compiler within should automatically be handling the differences between x86, x64 and Itanium. That’s the whole point of the JIT, right? The multilanguage versions? I can accept them, with reservations, but the different processor versions? I’m no expert on the PowerShell internals, but if it requires the .NET framework, that would seem to imply that it’s managed code, which would imply that the JIT should take care of the differences between platforms. And if it’s not managed code, why not? Is it that MS is saying that managed code is good enough for everyone else, but not good enough for them?

Reminds me of the discovery I made ages ago that Outlook communicates with Exchange via RPC, not via DCOM, even though DCOM was being pushed hard by Microsoft at the time. Another case of “good for you, not good enough for us”, perhaps?

Oh, and PowerShell looks like a very handy tool for Administrators. I’m sure I’ll find some uses for it eventually. But, get-childitems -path env: just to retrieve the current environment vars? There’s something to be said for mapping all sorts of various available info like that into a consistent interface, but my stack’s too deep as it is right now to pile this syntax on top just yet.