Evaluating the Wilson Web Portal
In a previous weblog entry, I summarily dismissed the Wilson WebPortal because it takes the ASP.NET 2.0 approach to web applications, about which I have grave doubts. However, three separate concerns have made me reconsider the Wilson WebPortal and, therefore, the ASP.NET 2.0 approach.
The first concern is that, as I have been creating Charlie, I have been getting annoyed by the amount of repetitive code I have been writing. One area is that old chestnut: data access. I’m brand new to databases, and have written about thirty CRUD methods, but already I am super-bored with data access. The Wilson WebPortal naturally uses the WilsonORMapper, so I am super-tempted to take the same approach.
Another area where I find myself repeating the same darn code over and over again is the code to compare one business object to another. Every single one of my business objects has the following boilerplate code:
public new static Boolean Equals(Object object1, Object object2)
{
if (object1 is Article && object2 is Article)
{
return ((Article)object1).Equals((Article)object2);
}
else
{
return false;
}
}
public override Boolean Equals(Object object1)
{
if (object1 is Article)
{
return Equals((Article)object1);
}
else
{
return false;
}
}
public Boolean Equals(Article article)
{
if (article.Id == this.Id)
{
return true;
}
else
{
return false;
}
}
public override Int32 GetHashCode()
{
return base.GetHashCode();
}Because these tests must be against the final type (such as an Article, or Blog, or Webpage object), this code to test whether one business object is equal to another cannot be moved into a base class. (At least, not in .NET 1.1.) But a peek at the code for the WilsonWebPortal suggests that generics provides a way to avoid this repetitive code. To date I have been unable to find an article on generics that makes the slightest sense to me. Fortunately, if you look at the documentation long enough, you get an “ah-ha!” moment when generics actually starts making sense.
So, the problem of repetitive code, and the simple and direct way in which Paul solves this problem, has given me the first reason to look at the Wilson WebPortal.
The second concern that has been haunting me ever since I started Charlie is the knowledge that I am reinventing the wheel. There are already mature applications that do the same thing, but I feel that they get it wrong—I honestly believe that I can do better. The Wilson WebPortal is not yet a mature application. It is brand-new, written from the ground up using the best that ASP.NET 2.0 has to offer. It is therefore free of legacy crap (like the remanants of IBuySpy that shackle DotNetNuke) and free of accumulated crap (like all the gee-whizz junk that bloats DotNetNuke). It is a clean slate provided by a guy who does things in a way that I both respect and admire. Paul’s only weakness is visual design, but that is where I can add real value to what he has achieved with his new product.
The third concern that has been troubling me is the knowledge that I am actively avoiding ASP.NET version 2.0. While I am compiling against .NET version 2.0, I have not used a single aspect of this new technology. In everything I have been doing, I have been doing it in a non-ASP.NET 2.0 way. What this means is that I am driving my project off the sealed highway and onto a dirt track that leads somewhere else. I fear that I am taking an ideological approach rather than a practical approach, which will come back to haunt me when I find myself stranded with an application that is too different in too many ways.
For these reasons, I am going to work through Wilson WebPortal, and learn how it does its thing. I will then either move Charlie onto this project, or I will keep Charlie as a separate project and apply the lessons learned from the Wilson WebPortal. Either way, I will try to bring Charlie back onto the sealed highway that is ASP.NET version 2.0.
by Alister Jones | Next up: The Monkey or the Gorilla? →
----
Post a Comment