Lesson: Objects Allow Emergence, RAD Does Not
By RAD, I mean Rapid Application Development. And by that, I mean the drag-and-drop-and-think-no-more approach taken by many users of Visual Studio. Need a navigation bar for your website? Drag and drop an XML-based sitemap source onto your page, drag and drop a Menu control onto your page, bind the two together, and think no more about it.
By emergence, I mean the concept put forth by Andrew Hunt. An emergent property is one that grows out of a base that was not intended to provide that property. If you look at your backyard you will, I hope, see some lawn. The intention is that it provides a nice green patch that the kids can run on and, if they fall over, not hurt themselves. But if you drop in a seed, a flower will emerge. If you drop in an acorn, a whopping great tree will emerge. The flower and the tree were not intentional properties of the lawn, but they evolved because the lawn provided a fertile base. (This is my own interpretation of Andrew Hunt’s use of the term. If this analogy does not match what Andrew meant, then the error is all mine.)
Let’s return to the example of the XML-based sitemap source used by the RAD developer. This solution requires a SiteMapDataSource control in the Interface layer, a SiteMapNodeCollection in the Business layer, a SiteMapProvider in the Data Access layer, and an XML source file. So here is the solution:
Next up, the RAD developer needs a bit of localized text. .NET accommodates the developer by providing a ResourceManager that manages separate Resource files, each of which is drawn from satellite assemblies. Here is the solution:
Finally, the RAD developer needs to store some information about the current user of the website. .NET provides a Profile object, with its own Provider, and stores the information in a self-configured SQL 2005 database. Here is the solution:
Each of these is a forced solution, designed to support RAD developers. They are designed separately and differently, they are implemented separately and differently, and they are used separately and differently. Why does localization use a Manager when the others do not? Why does localization not use a Provider, when the others do? Why does one use an XML store, one use an assembly store, and one use a database store? And I have provided just three examples. Consider the variety of separate and different approaches across the full ASP.NET framework. (I’m sure there’s a tautology in that last sentence, but I don’t think any English lecturers read this blog.)
The point is that none of these solutions emerged naturally. They are each banged in place to support RAD developers, with no rhyme or rhythm connecting them.
When I designed the Entity System for Charlie, I did so only because I had read Expert C# Business Objects, and I kind of liked the idea of a few base classes on top of which I could create my business objects. In other words, I went to the effort of creating the Entity System just so that I could be lazy later, and do a minimum amount of work to create business objects. That was the sole motivation for the Entity System.
What is interesting, however, is that this Entity System allowed other solutions to emerge—solutions that the Entity System was not designed to provide. When it came time to globalize Charlie, I did not have to implement all the separate pieces shown above. Rather, I just added a Culture property to the base Entity class, added a Culture property to the base EntityCriteria class, and added a Culture parameter to the base EntityMapper class.
When it came time to provide security, I did not have to implement all of the separate pieces shown above. I simply gave the base Entity class a set of CreateRoles, RetrieveRoles, UpdateRoles, and DeleteRoles, and told the EntityManager class to check whether the current user was in the appropriate role collection.
Most recently, I had to implement a sitemap for Charlie. I looked into the sitemap system in ASP.NET version 2.0, and ended up thinking, “To hell with that.” I already had a DocumentCollection class based on the EntityCollection class. I simply created a new DocumentMap entity, and gave it a property that exposed a DocumentCollection. And with that, I was pretty much done.
Before you think that I am patting myself on the back, I’m not. The Entity System was a simple thing created so that I could be lazy. Yet because it was simple and flexible, solutions emerged from its fertile soil. No foresight on my part—the emergence of these solutions has surprised me.
The lesson for the day, then, is that a little bit of object-oriented design leads to a surprising amount of emergence. Feel free to ignore ASP.NET’s own complex solutions, and let simple solutions emerge from your own codebase.
by Alister Jones | Next up: Lesson: Show Simplicity, Hide Complexity →
----
Post a Comment