Friday, December 29, 2006

Web Applications: One Page or Multiple Pages?

ASP.Net is a very powerful programming context, and prior to my introduction to it when I got my job, I was happily a PHP-man.

Frankly, I love the power which ASP.Net provides to programmers developing web applications. The PostBack model, though it can be duplicated in PHP and classic ASP, is a wonderful thing. And it led to some interesting ideas on developing web applications.

Some backstory first. The first ASP.Net site I built was a massive thing, there were three programmers working on it, and we had a 100-odd page design document. This site contained 8 "master" pages, plus another 6 in the administration section. Each "master" page utilized a number of user controls, some shared, others specific to a sub-section.

The next major web application I worked on, I had a bit more hand in designing, and we had a single ASPX page, with everything else user controls. This web application builds documents (and is in use, and still under active development today). And by the time we added in the third document type, the limitations of a single web page became obvious as under a security certificate, there was too much data being passed down the pipe due to all those user controls.

We're talking nearly a meg of data just from the ViewState.

Various scrambling to resolve the issue presented us with a quick-dirty fix so we could deploy the document type in question, and lead me deep into the inner workings of ASP.Net to try to find a more permanent solution. I did find one, and it works beautifully - but that's a story for another day.

While rebuilding my personal website (http://www.krashpad.com), I utilized the same concept for a website. A single page - where content is flipped in and out of controls based on postbacks. In other words, if you click the Archive button, my custom ContentDisplay control goes away, and my custom ArchiveDisplay control appears.

It's great, beautiful. Wonderful from a programmer's POV. Everything I expected and more!

And an utter failure.

Why is it an utter failure? The answer is: because it is a single page, driven entirely by postbacks.

Yes, the very thing I set out to accomplish with the site is the reason it fails so spectacularly. People can not link directly to content. People can not link directly to the Archive. To do anything, you have to go to the main page and perform some combination of clicking on LinkButtons.

Needless to say, I will be fixing it. And I guess the point of this is just to make sure that beautiful programming ideas fit the type of web application you're building before implementing them. While the single web-page concept is great for a web application which builds documents based on user input - it fails utterly as a concept for a content-driven website.

Thursday, December 28, 2006

3-tiered Data Architecture Tutorials.

ASP.Net (the website) has a series of tutorials on building a three-tiered data architecture using ASP.Net 2.0 (view the tutorial here).

And for the most part, it is a good series. The only thing that I kind of disagree with is their decision to use typed DataSets as the data access layer.

While sure, that creates a form of data independence, as you're not building SQL strings through out your code, it still doesn't feel like a data access layer.

Personally, on sites that I may need to switch the back end database for, I create an interface, which performs all the tasks I need, plus a few extras, such as RunStoredProcedure, RunNonQuery, RunQuery, and GetDataSet.

Since there is an interface for all DataReaders, I return that from my interface - giving me the ability to be database agnostic.

The code class that I use for manipulating the database I will place in a separate DLL, and then use reflection to instantiate that object in the Global.Application_Startup event handler. Making my data access layer, a global object (where I've long stashed other global variables which are stored in the Web.Config file).

So My project solution will look like this:

  • Web Project
  • Database Interface
  • SQL Server Data Accessor
  • Oracle Data Accessor
  • MySQL Data Accessor
Sure, there is a slight performance hit on using reflection and late-binding the data access layer, but that is a trade off I willingly took for my code to be database agnostic.

Wednesday, December 27, 2006

Are strings better in the database or VB.Net code?

I'm an unabashed code man. And while I firmly believe that some operations should always be carried out inside the database, I also firmly believe that there are some operations which it makes no sense at all to run within the database.

And I find myself occasionally bumping heads against one of our engineers that believes any type of data manipulation belongs within the database.

My thought is we need to create a simple platform to test it.

Basically, here's the situation. We have a web application which prompts the user for data and then builds a large RTF file from the user entered data in addition to boiler plate text. An RTF file is nothing but a large specially formated string - and since the creation of that string is data manipulation, he believes that it should be done within Stored Procedures and Functions within the database.

My argument is that it needs to be tested and metrics generated for both creating that large string in the database and creating the large string within a VB.Net class using StringBuilder.

Unfortunately, I am unable to find any metrics or tests saying that building strings is more efficient in one form or the other, which surprises me slightly. One would think that such ammo would be used loudly and often by either the all-database or the all-code sides, especially in the war over using Stored Procedures to access all data in SQL Server.

And while I know that SQL Server 2005 has the new LOB's, we're still using SQL Server 2000 for this project, so we're dealing with VARCHAR(8000) and TEXT fields. And manipulating TEXT fields is down right evil within SQL Server.

Of course my hesitation to embrace this could be based entirely on the desire to never work with large string objects in SQL Server and everything else is just mad justifications to support my on biases, but I think I will be running the tests when I get some free time just for myself.

Tuesday, December 26, 2006

The Alphabet Soup of Design Documents

ORD, SS, SRS, SDD, DBDD, IRS, IRD.

If that list of acronyms makes sense to you, then congratulations, you're in my field of work. They have recently taken on a more...pressing meaning for me, as for the first time in my professional life I have had to write the things as opposed to just use them to create software systems.

This would not be that bad if my college coursework had actually prepared me for the proper creation of these documents.

My job title is Software Engineer. I am supposed to be able to design and develop software systems. Yet my college coursework was long on developing and short on designing. Out of the many, many hours of credits for programming, only 6 were spent even remotely dealing with design - and even then properly creating a Systems Specification or deriving Requirements from the SS were not really the focus.

So, I have spent hours of hours of OJT learning to build these documents, mainly through trail and error, and I am thankful for a crusty old retired naval officer who is my company's Senior Systems Engineer who is able to provide me feedback on how I'm not doing these things right.

Oh but to see the proverbial red ink all over my documents.

Anyways, I did find a few links online that helped me (or harmed me, the jury's still out on that) and thought I would share them here.

Of course those things might not meet your company's needs for an SRS, and the one thing I found is that there are multiple ways of creating these documents. The more important thing is are you going to use Functional Decomposition or Object Oriented Design. And if you are still in college, then I highly suggest you try to find a course where these theories are taught by practical experience rather than book work.

Blog Widget by LinkWithin