Hmm - yes, you are probably right...
Barring what the others have said about "use a real database", here is what
I would do:
1. If the xml is pretty stable, then you could put it in the Application
What I usually do is write a method:
public void XmlDocument GetTheDocument( bool forceRefresh )
//if the object is in the Application cache, return it
//if the object is not in the cache, create it , put it in the cache
//if the bool forceRefresh is set to true, ignore whats in the
Application object, get the freshest, put it in the cache for future people
2. If you want to query on it, then you'll have to write some XPath
statements, and use .SelectSingleNode or .SelectNodes
Working wiht xpath's and nodes is ... heavier than I like. So let's go to
3. If the xml is in a format you can't control, you may be able to massage
it into DataSet friendly xml.
Why? If you could take the xml, make it DataSet friendly, and create a
strongly typed dataset for the data, you could have an object you can work
For Select's and Row additions and such.
and after you read it (its quick) you could do something like
MyStronglyTypedDS ds = new MyStronglyTypedDS();
ds.Authors.Select ("LastName='" + "Smith" + "');
Alot less Xpath stuff.
4. Look at this also:
You can easily convert it to use Application (instead of Session). And have
a smarter holder.
Throw in some 2.0 Generics, and you can get slick with it.
That code is just a fancy wrapper for the Session object. But I like it
alot better than coding directly against the Session object.
"Yehia A.Salam" <yehi
@hotmail.com> wrote in message