Building a “Stupid Client”… Part 1

Everyone always talks about building “Smart Clients”! Well what about building a “Stupid Client”? In today’s day and age it seems that buzzwords rule the market place, so I kind of want to create my own. I am constantly faced with the same question: How do we deploy a Windows Application that can be easily updated even when business logic changes? The answer is kind of simple, and I don’t know if someone has already thought of it. I have a lot of “good ideas” and find that someone else has already implemented them…

At any rate, the point is that as a Manager/Architect/Developer/End-User/Consumer etc. you do not want to have to “update” software often. Deploying new versions of any client software is costly, both in terms of bandwidth (kind of cheap now) and in terms of time, testing, and potential failure upon update. This is the reason that you do not want to let a front end application have any knowledge of the complex types that may be dealt with on the server side. What do I mean? In an N-Tiered distributed application we may find the following scenario:

In most instances the front end client will communicate with our application server through a webservice. Some environments split the webserver and application server, however for simplicity’s sake we will just say that they both reside on the same machine. The client needs to be as dumb as possible. If you build business logic into the client application, even as much as checking a simple value, you will find yourself updating the client to accommodate business rules. In my span as a software developer I find that business moves at blinding speed! Marketing initiatives, competitive strategies and business plans all change so fast that they will make your head spin. So building a “Stupid Client” may help you slow down your software deployment cycles. So how is this achieved? Well one thing that I like about the MVC (Model-View-Controller) model is that it promotes a “Stupid Client”(View). Following link offers a quick explanation:

http://en.wikipedia.org/wiki/Model-view-controller
So with that model in mind we find ourselves looking for a good way to pass data back and forth between our client and the back end server(s). If your client is a Web application you can communicate with the business layer rather easily since that resides on your webserver(depending on your infrastructure architecture). Windows applications are a different beast; they reside on the user’s box. So how do we send mass amounts of information back and forth without letting the client know about our complex business objects? Datasets, reflection and a simple design pattern.

So, to start we will examine the design pattern. The BUILDER pattern moves construction logic outside of the class being instantiated.

http://www.dofactory.com/Patterns/PatternBuilder.aspx

We will use some of the concepts that Builder introduces, although not a true builder.

As I said the builder pattern removes the build logic from the specific class that we need to build. In our case what we will need to do is allow our builder to provide us with a new instance of our business object. Generally the builder pattern provides more specific functionality. We will build a generic builder…

The idea behind our Builder class is that it will rebuild a Dataset into an object, hydrate it, and then allow it to do its work. So how do we go about doing this? The diagram below explains the concept.

With that in mind we should be ready for some code. I am still working on that piece. It is almost done, but it will require a writeup that is equally lengthy. So stay tuned, that will be out in the next couple of days.