Author: Chad Stoker
I'm a Senior Technical Architect for a Government Agency and a Contractor. I've worked in the .NET arena for quite some time (4+ years) and was put in a position where I needed to develop an Agency-wide Web site that had Content Management capabilities... but had a highly customized look & feel. Our Contractors chose the Rainbow Portal since it was written in C# and seemed to have lots of features already built in. Everything looked like it would run smoothly... except nothing ever runs smoothly.
Because Rainbow was largely thrown together by disparate Groups of individuals from all over the planet, the Architecture of Rainbow also looks like it came from random places all over the planet. Case-and-point, the Navigation Menus. Anyone that delves into this will realize that Rainbow opens up a new Connection to the SQL Server upwards of 5 or more times PER ITEM on the Navigation Menu. So say you have 50 or more items in a fly-out navigation structure, then you will be opening a minimum of 250 SQL Connections per page request!
Rainbow attempts to resolve this oversight by Caching some of the information that it needs which cuts down on the number of SQL Connection requests for that page, but it re-performs the SQL Connection madness again when the User selects a different page!
The URLBuilder class is a notorious Object that seems useful enough. Maybe you want to use it to navigate to the same image from multiple places in your Portal. You might use the URLBuilder for that. BUT LOOK OUT! Even if you're just trying to point to an Image, behind the scenes, the URLBuilder is opening up a SQL Connection to the Database! In fact, when one requests a SqlString from the PortalSettings class... (the main class utilized throughout the Rainbow Framework) it returns a new SqlConnection object every time. It doesn't bother to check if one is already being used.
The problem with this is that in several situations, the developers of various Modules and Framework components didn't realize how related their items might end up being. So Module developers would just make multiple calls to the SqlConnection Property of Portal Settings and get a SqlConnection assuming that it would all be handled efficiently. That is an incorrect assumption with 85% of the Rainbow Portal.
If you're planning on using this Framework for developing a website, I STRONGLY encourage you to think about how big the scope of your project is. If it's BIG, expect to be overhauling and gutting 80% of the Rainbow Framework so that you can make it efficient enough to handle 1 million hits per month... and thousands per day. If you think you don't have the time to work and understand Rainbow, then buy a Product that has better support. If you are just developing a small website, with no flyout navigation.... or your flyout navigation is only one level deep, then Rainbow should be fine for you. That is, if you don't get a high-volume of page requests.
The number of Modules developed for Rainbow is worthwhile to take a look at to see how all of these things are done. However, expect to be re-architecting them once you understand the basics of how things like the Documents Module, the HTML Editor, and the Events Module perform their core functions. For the simple fact that Rainbow had lots of Cool Modules "out of the box", I gave this Portal a 2, which is above the lowest rating... slightly.
