Chan,
Like many other things, there are a lot of opinions out there, including ours. StrataFrame is not a science experiment, it is a living, breathing framework that is the crux of our company. The reason that we created StrataFrame is for our medical application which then turned into another line of business. To date, I still have not seen another application as large as our medical application that covers all environments, from distributed using Enterprise Server to online ASP.NET. In all cases, we have wonderful performance and only run into memory leaks that are self imposed. Like anything else, application design can play a role in a memory leak. If you create an object and forget to dispose it, etc.
Also, Chan, I know that at one time you were apparently not having this issue. Which means that you did at one time run with StrataFrame, in this environment without having a memory leak. We have not changed our technology in regards to the data table. So there is most likely something else in the mix.
I write a phenomenal amount of rendering code. In our medical application, our charting environment is heavy GUI and graphics rendering. As such, I have to be careful not to introduce memory leaks. The most common accidental leaks that I see are:
- Event handlers that are not removed
- Objects that are not disposed
So it is possible that a new handler is not being released, etc. All it takes is one and everything will stay in memory.
As for the base pages, you don't have to have a single base page. You can programmatically add in BOs into the session just as thought the page had done it and trick the environment. Generally on large scale ASP.NET applications it is a good idea to create a session environment handler to create and dispose of the BOs. This is just memory management and puts you in control of the disposal. For example, you could create a static class that loads and unloads your BOs as you need them. You can tie this into a single base page if you like, but this would be more class and application design as to what would meet your needs.
Breaking Down the Session
The nice thing about StrataFrame is that you get the source code. If you open the MicroFour StrataFrame UI assembly and then open the WebForms->BasePage.vb, you will see that in the page pre-load, the InitializeBusienssObjects method is called and loads (or unloads) the BO from the session. You can do this yourself in your own environment and manipulate what is coming in and going out. This also puts you in control of the disposal, and adding only the BOs that you need into memory. You could still define them all in one page if you like, then override the pre-load and add your logic to actually implement this functionality.
If you look, reflection is used to determine which properties are BOs. That property becomes the session variable name. So if your property name is "MyBo" then the session variable name will be also.
//-- Extract the BO from the sessionMyBo extractFromSession = (MyBo)Session("MyBo");
//-- Remove the session variableSession.Remove("MyBo");
//-- Dispose of the BOextractFromSession.Dispose();
Reverse this to put it back in. You can then have your own class that manages this as you feel it is necessary.
Working with Grids
Anyone who knows me knows that I am not a fan of grids. I believe that there is a time and place for grids, but throughout my development career, the one control that constantly brings trouble either into the UI or the development environment is the grid. The reason is that the grid is created to be a "magic bullet" for practically any environment which brings tremendous overhead. There are a few, non-invasive places that I have used grids. And they are generally on the web as the DataGridView has a low overhead compared to other grids, so I extend it for my needs. But usually, I create a web control.
When you create your own web control, you can make it look and act as a grid in most scenarios. But you can do it at a fraction of the overhead and properly create and dispose of objects and handlers. This is the approach that I generally go as you can make this far more custom, far faster, and it will have far less overhead.
Some people prefer to stick with pre-fab or stock controls that can be purchased, but this always comes as a cost on the web. I am a fan of controls and control collections, but there are some controls that just are too "fat" to be effecient. That is when I start trying to take the best of the pre-fab or stock controls and then create my own for the areas that are proving to be a hindrance to the development cycle. Most developers think that this is too time costly, but in the end, you save time. Otherwise you deal with issues like this on a perpetual basis.
I hope that there is something in here that helps, as I do want to help, but I am not in control of all of the pieces. I will do what I can, but that is all I can do.