Re: Global datasets
- From: "Dan Bass" <na>
- Date: Thu, 16 Nov 2006 08:59:36 -0000
First thing I notice is your constructor for Folders should be private.
Otherwise you can delcare it outside of the singleton pattern and it breaks
the concept. By being private only SiteFolders can create a new instance.
The second thing you've encountered is the use of statics in ASP.Net... In a
windows form application, the use of static keeps the object in memory until
the application is closed. So if you have a static integer that acts as a
counter in an object, the object can be destroyed, and recreated, and the
value in that static will persist if it's not explicitly reset. But on the
web side of things, static's are used to store Application wide data. So if
one user came in and the object was created, then a second user browsed the
page, they'd be referencing the same data as the first.
Now you'll never guess what, but I've gone back to the starting point I made
in the first thread. You're looking more into cached objects, rather than
global, in that the object may be hidden away somewhere for set period
(whether the life of the page or life of the session) rather than a global
object that's about for the lifetime of the application. I've never been too
sure of the scope and duration of objects that are made static, and have
tended to move towards session objects that are persisted on a per user
basis...
So we've got 3 things to look at.
- Application wide data store... It's initialised typically in the
Application_Start event method and each user hooks into the same data
- Session wide data store... Each user has their own object, but it's
typically initialised at the start of the session when the user connects for
the first time, and expires with their session.
- Local data store... This comes back to having an object on the Page
object, that is then passed into each object that uses it (sounding like a
broken record player I suspect). This time the object is created typically
each time on a post back, and is expired once the postback cycle is
complete. So the life of the object is really a few seconds while the page
loads up the data.
How long do you need to keep your data for? If it's just for the cycle of a
page loading up, then 3's the answer I'm afraid.
Cheers
Dan.
"David Colliver" <DavidColliver@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:3A2028C1-EA41-49F5-9C87-AF63717F9367@xxxxxxxxxxxxxxxx
I think I may have something, based on a singleton (I think).
public class Folders
{
private static Folders mObj;
public Folders()
{
Response.Write("something");
}
public static Folders SiteFolders
{
get
{
if (mObj == null)
mObj = new Folders();
return mObj;
}
}
private int _FolderID;
public int FolderID
{
get { return _FolderID; }
set { _FolderID = value; }
}
}
In my page, I can do something like...
MyNS.Folders MyFolders = MyNS.Folders.SiteFolders;
MyFolders.FolderID = 20;
Response.Write(MyFolders.FolderID);
With my response.write in the constructor of the Folders class, I can see
that no matter how many times I call the class using the code above, the
constructor is only called once.
HOWEVER, I have also found that each time I refresh the page, the
constructor is never called again, unless I re-build the project. It seems
that the object persists in memory. Whilst this may not be a bad thing, I
do
need some way to kill this persistence, for example, if I add new folders.
How can I do that?
Also, can you see anything wrong with my code? I will continue with what I
have and see how far I can take it.
Thanks for your help.
Regards,
Dave Colliver.
http://www.AshfieldFOCUS.com
~~
http://www.FOCUSPortals.com - Portal franchises available
"Dan Bass" wrote:
David,
I'm afraid I've not looked into the MS CMS so can't relate to what you're
saying...
In your below example though, Channels needs to have been created
somewhere,
as you said. The reason you can use the code anywhere is because
CmsHttpContext obviously has global scope. It'll be global because it's
inherent to the context it is in, created at an earlier point, then
exposed
as a property. From this I'm understand your query a little more, I
suspect
there is some parent class here that is initialising these objects "under
the hood".
Basically, to get to the same point with the dataset, you WOULD follow
the
property route. Because you can't see that how the channel array is
populated, it doesn't mean that you got the "global-ness" (there's a new
one!) of the object for free... the framework outside what you saw did
this
work to give you access to this object.
Good Luck!
Dan.
"David Colliver" <DavidColliver@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:E3C8C941-BB4D-4B6F-ADD1-FE072FB98E93@xxxxxxxxxxxxxxxx
Hi,
Thank you so far...
I understand what you are saying here and I have done similar in the
past
(and done it the other way around, where the UC calls the property from
the
page instead of the page pushing the property).
Do you know Microsoft CMS? Here is what I am trying to achieve with
slight
differences.
Channels MyChannels = CmsHttpContext.Current.Channel.Channels;
foeach (Channel ch in MyChannels)
{
Response.Write ch.DisplayName;
}
Now, what I notice is that the MyChannels is not using a "New"
statement.
So
(I may be assuming wrong) what I assume is that the
CmsHttpContext.Current.Channel.Channels is already instantiated and
running.
I can quite simply use the lines above ANYWHERE in my code and it will
work.
No mucking about with properties, pushing datasets or anything like
that.
(obviously, there is a using clause as well).
To add to the confusion, I need to develop this at a slightly lower
level.
My page codebehind class is...
class page : MyOwnPageClass.Page
My own page class is...
class Page : System.Web.UI.Page
I use a similar sort of thing for my controls. This will allow any
developer
to create pages deriving from my page class with the functionality that
I
need to add to the page.
Coming back to singleton, I only want to create it once and use many,
but
I
am not sure of the scope of the singleton. At this point in time, I
want
the
page to create the menu (somehow) and be available for the life of that
page.
(doesn't have to survive refreshes, postbacks or anything, just the
instant
the page is running.)
Regards,
Dave Colliver.
http://www.Burton-on-TrentFOCUS.com
~~
http://www.FOCUSPortals.com - Portal franchises available
"Dan Bass" wrote:
David,
The singleton architecture was simply a way of having a "create once,
use
many" type scenario...
What you've said suddenly shed light on the situation, if you're
coming
from
an ASP background into this, then I can understand why you're trying
to
go
about what are. Unfortunately for you though, I'd still have to come
back
to
what I said before! ;-)
Typically I'd see it like this:
-------------------------- Page Psuedo Code
class myPage
{
DataSet myData = null;
void Page_Load (...)
{
if ( !Page.IsPostback )
{
if (myData == null)
{
// create and populate dataset here
}
// pass the data set we've created through to the controls
on
the page
// If the controls are loaded dynamically, then where ever
the
controls
// are loaded should contain this logic...
foreach (Control on the page)
{
eachControl.MyDataSet = myData;
}
}
} // end of Page_Load
// other page code
}
-------------------------- User Control Code
class myUserControl
{
// define this dataset locally and ensure it can be referenced as
a
property
DataSet myData = null;
public DataSet MyDataSet
{
get { return myData; }
set { myData = value; }
}
void Page_Load(...)
{
if ( myData != null )
{
// bind the DS to the control here... Note we should
already
have
// a valid instance here since the Page gave us a valid DS
before this
// method is executed.
}
} // end of Page_Load
// other control code
}
Hope that helps, and if not, keep probing, we'll get there. ;-)
Dan.
"David Colliver" <DavidColliver@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:0AADDAD4-C797-44AE-96B7-0CE1CF405A44@xxxxxxxxxxxxxxxx
Thank you for sticking with me.
I may be mis-interpreting what you are advising me. If I am, I
apologise.
I need a dataset (actually, an ienumerable, based on the datatable,
but
saying dataset would make things simpler and I can take it from
there)
that
is the menu structure of my site.
When the dataset is created is of no matter, but all objects (pages,
controls, UCs etc) must be able to read it (pull from the dataset).
The
dataset must only be created once, but can be read by no, or many
items
that
require to read it.
The dataset class itself should not know about the objects that call
it.
It
has to be the object that pulls the data. To me, this is then a
global
dataset, a dataset that can be seen by all objects.
Imagine a classic asp scenario...
'Create dataset. PSEUDO CODE, NOT ACTUAL
DS = createobject("recordset")
'This DS could be in a seperate include file is need be...
function CreateMenu
'Use DS here
end
function CreateBreadCrumb
'Use DS to write breadcrumb
end
function BuildPageContent
'No need to use the DS here
'but should I need to, it is available.
end
As an aside, I tried creating a singleton last night (after doing
some
looking), but that is not quite working properly. Probably because I
don't
really understand (yet) what I am doing with a singleton.
Regards,
Dave Colliver.
http://www.AshfieldFOCUS.com
~~
http://www.FOCUSPortals.com - Portal franchises available
"Dan Bass" wrote:
David,
At this point it's probably worth taking a step back and describing
a
bit
more what you are trying to do. For a minute, forget Page_Loads,
Global
variables and user controls, and try to describe, independently of
ASP.Net
or any other techonology, what you are doing.
Again, what I'd do is to have a property on the usercontrol that is
a
DataSet object, then when the page creates/loads the control it
passes
an
instance of the DataSet through to that control. Now I know you've
said
that
your pages may never know what controls are added, but this is,
well,
impossible. Some code somewhere add's the controls to the page. So
whether
it's done at design-time, or dynamically at run time, something is
adding
the controls to the page. It is as this point that the DataSet is
created,
and passed into the controls.
If you're still not in agreeance with this approach ( ;-) ), then
go
ahead
on the first part, and descibe broadly and generally what it is
you're
trying to accomplish and we'll see where we go from there.
Thanks.
Dan.
.
- Follow-Ups:
- Re: Global datasets
- From: David Colliver
- Re: Global datasets
- References:
- Global datasets
- From: David Colliver
- Re: Global datasets
- From: Dan Bass
- Re: Global datasets
- From: David Colliver
- Re: Global datasets
- From: Dan Bass
- Re: Global datasets
- From: David Colliver
- Re: Global datasets
- From: Dan Bass
- Re: Global datasets
- From: David Colliver
- Re: Global datasets
- From: Dan Bass
- Re: Global datasets
- From: David Colliver
- Re: Global datasets
- From: Dan Bass
- Re: Global datasets
- From: David Colliver
- Re: Global datasets
- From: Dan Bass
- Re: Global datasets
- From: David Colliver
- Global datasets
- Prev by Date: Re: Client Side Script window.open
- Next by Date: Re: global.aspx and web.config
- Previous by thread: Re: Global datasets
- Next by thread: Re: Global datasets
- Index(es):
Relevant Pages
|