Where are all the class libraries?

I’m often asked why class libraries aren’t supported on an application diagram. At first glance the diagram seems like it should support visualizing all aspects of application structure. In Whitehorse we use the term application loosely to talk about a collection of systems that serve some purpose and then more precisely in a slightly different context to refer to a discretely configurable and deployable entity – typically deployed into a single app domain on a single server. These are the applications that show up on the application diagram. While an application in this latter sense is atomic from a deployment perspective, it is still an abstraction – normally an application comprises a root entity (often a root project) and a set of resources deployed with it, which are considered to be part of the application and not part of the hosting environment or the infrastructure. These resources may include class libraries, config files and other resource files.

A key part of the Whitehorse model is the notion of composing systems from one or more applications to describe what is actually required for a deployment. When a class library is referenced by an application the configuration of the class library is determined by the application that uses it – thus the value of a web reference URL or a database connection string required by a class library is provided by the root app.config or web.config, not the app.config defined in the class library. Think about this situation - a class library that makes a database connection is referenced by two applications but in each case is configured differently to connect to two different databases. If we added the class library to the diagram how would it be connected? How would you indicate that the connection was determined by the context in which it was called?

The solution is to not think of class libraries and other resources as peers of an application but as part of its implementation; instead of seeing them connected alongside the application on the AD or SD one should drill-into the application to see them in context. So in the same manner that a system can delegate its behavior to its members (other systems or applications), an application delegates its behavior to the projects, class libraries, dlls, etc within it. We’re thinking therefore of enabling a drill-in view which would expose the structure of an application and the delegation of its endpoints. You'd be able to define where in the structure a specific web or database reference exposed on the application as a consumer endpoint is implemented, or where the services provided by the application are implemented.  

It’s likely that this drill-down view would be in a separate designer/diagram – think double-clicking on an app on the AD or SD to open the drill-down view, where you might see the root project and a nested hierarchy of class libraries/dlls contained within an outer application shape. Each endpoint on the outer application shape would be delegated to either the root project or one of its referenced modules. While this drill-down view could be shown expanded in situ on the AD/SD we’d more likely use a separate diagram to visualize each application – the use of a tree structure for the drill -in view wouldn’t blend well with the graph-style routing used on the AD/SD. This designer would also address the problem of copying the config entries from a class library into the config file of the root project.

So while I know there are tricks people have used to make class libraries show up on the AD I hope you can see why we don’t think this is a good idea in the long run. Doing this will not be consistent with anything we do in future.

Comments

• Anonymous
  October 16, 2007
  That is interesting considering latest development VSTS2008 Beta2
• Anonymous
  January 26, 2009
  I've not lost enthusiasm for this blogging thing, its just that I've been asked to convert some of my