Some time ago, when I was investigating e-commerce shopping cart applications for my furniture business, I came across AspDotNetStorefront. I decided to demo the application, and after some time, I determined that while the functionality would work, it was not the best solution for my furniture store. I then spent roughly eight months of building my own shopping cart, only to have the furniture representatives change the business model on me, ultimately forcing me to conclude my endeavors with the furniture business. A number of months after my promising business model collapsed, I was asked by two customers to build them shopping cart applications.

I chose to revisit the AspDotNetStorefront solution, and have since invested time and money into customizing it. As I find more time to become involved in the code, I am seeing that it will require more time to improve the framework. I bought this solution after thinking the demo application met and exceeded my needs. Since I could not see the source code during the demo, I guess I was not prepared for what lay underneath the hood.

The AspDotNetStorefront solution is comprised of three projects: a web UI, an admin UI, and a common BLL, which integrates both the BLL and DAL. Initially, I get the app running, see that it works, and then decide to begin customizing. I start off by skinning the site. I then realize that both the web and admin UI's are hard-coded in server code. If I want to change the HTML of a table structure, or create a new CSS class for a table cell, I must recompile the application itself. For example, the application's Default.aspx page actually gets its HTML rendering from the server, in the form of

Response.Write("<table width=\"100%\" cellpadding=\"2\" cellspacing\"0\" border=\"0\" style=\"border-style: solid; border-width: 0px; border-color: #" + Common.AppConfig("HeaderBGColor") + "\">\n");

"Hmm...," I thought, "this is not good, and will certainly make reuse of this site extremely difficult for multiple customers."

"OK, not to worry, don't panic," I pondered out loud, "I will create a custom assembly for each of my customers, and load that into the application's bin directory at run time, calling my methods with reflection." My Default.aspx.cs will now create a new instance of my custom object, cast that to an interface I specify, and call the GetContent() method of the interface. While that proved to be simple for the Default.aspx page, unfortunately, I must visit about 22 ASPX pages for just the web UI, and more for the admin UI. This ecommerce solution, which was supposed to save me time, is actually costing me more.

A few things I have observed. When building a web UI, design the application for ease of reuse and extensibility. Duplicating code is bad, and designing the HTML interface within server code is horrible. Create modules for reuse, not a new page for each module's functionality. Determine similar tasks and functionality, and design for them. Put as much style information as possible in CSS. Separate the BLL from the DAL, what if I want to change from SQL to MySQL? The list goes on.

As it stands now, I will be creating a new BLL for each client, after stripping out as much coupled code as possible from the web and admin UI's. I will not invest anymore time than is necessary to rewrite their app, but if I want to be able to use the same code base for multiple clients, this appears to be the best way. Fortunately my first client is flexible with time.