|
Hi all.
I'm re-developing a Data Access Layer Manager (codeplex.com/dalm) and have some architectural doubts about some of the I/O operations.
The problem
All queries are read from an XML file which is loaded into memory on first run. When a query is requested to be executed, the DALM will read from memory. Now, if the query doesn't exist in memory, the XML file has to be read again. But while reading the XML file, queries that does exist in memory should still be retrieved and executed. I have been using ADO.NET DataSet to read XML until now.
1st solution
When the a query is not found, the thread will continue to a "read xml statement" which will be locked using the lock keyword. This way other treads will still be able to access the DataSet. The problem is that the threads that also didn't find their query will continue to a "read xml statement". A solution could be to load all the threads into an Array, fire an event which will load the XML and then call the "find query" method recursively. The array would function as a Queue.
But how does threads behave when you put them in an array? Won't they continue? And if I continue to use DataSet, won't there be a moment where threads will get access denied exceptions, when I change the reference to the new DataSet? Loading grafs XML is not an option as I want the XML file to be human editable, ie. simple.
2nd solution
Dunno - something better? Maybe there is a pattern that doesn't require any locking at all?? I've looked into immutable stacks (http://blogs.msdn.com/ericlippert/archive/2007/12/04/immutability-in-c-part-two-a-simple-immutable-stack.aspx[^]) to see if I could somehow synchronize without locking but I'm not sure how to apply it to my problem.
I hope this triggers some ideas!
Thanks in advance, Jon
If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done - Peter Ustinov
modified on Monday, July 21, 2008 3:40 AM
|
|
|
|
|
Maybe some code would help? Any questions or is it just too tough? 
If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done - Peter Ustinov
|
|
|
|
|
Doesn't matter - I figured it out
If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done - Peter Ustinov
|
|
|
|
|
Does anybody has an idea about the slide sorter in power point. The items inside the slide sorter are thumbnail or an actual live controls that contains different types of shape objects. The reason is that i created 200 slides and when i opend the file it opens instantly. I want to know how powerpoint manages this kind of performance if they are are thumnail images or Controls
Thanks for replying
|
|
|
|
|
I would suspect it uses precached thumbnails. As I don't work on the Powerpoint team, this is just my guess however but it does seem likely.
|
|
|
|
|
Thanks for answering and too bad for me you that you aren't in their team. So you think that each time when we move a shape on the screen a thumnail image is created again for that item in slide sorter. Moreover, what about when we type a word does slide sorter recreate a thumnail.
|
|
|
|
|
netJP12L wrote: Moreover, what about when we type a word does slide sorter recreate a thumnail.
Possibly, and maybe probably.
|
|
|
|
|
I was reading an interesting article[^] in Dr Dobbs on event based architectures. In the article, the author describes an architecture in which objects are almost completely decoupled from each other. This is done through events. Say you have object A that raises an event. Object B is interested in this event. A third party called a binder binds these two objects together without either one of them knowing about the other.
This can be easily accomplished in C# using events and delegates.
public Binder()
{
a = new A();
b = new B();
a.SomethingHappened += b.HandleSomethingHappened;
}
However, in playing around with this type of approach, I've noticed that it may not scale well. The problem is that the binder object has all of the responsibility of connecting the dots. This can lead to a ton of configuration code (usually in the binder class's constructor), and it's easy to forget to hook everything up. "Oops! I forgot to hook B to A or was it B to C?" That sort of thing.
So I've considered modifying the approach in which each class knows what events it needs to hook to; it does so by taking an object passed to its constructor and hooking to the relevant events. This approach involves greater coupling. The target of an event knows about the sender. But on the other hand, it relieves the "binder" object of having to know how to hook everything up. All it's responsible for is passing the event raising object to the receiver.
public Binder()
{
a = new A();
b = new B(a);
}
public B(A a)
{
a.SomethingHappened += HandleSomethingHappened;
}
This also has the advantage of giving B the option of making the method responsible for handling the event private or protected so that it's hidden from the outside world.
We can minimize the coupling by using interfaces that expose only specific parts of a class's overall functionality. Then only a reference to the interface is passed to the target class thus limiting its knowledge of the event raiser.
Thoughts?
|
|
|
|
|
If you're interested in loose coupling in your design, I would definitely take a look into Dependency Injection. BTW - what you described initially sounds to me like a variation on the Mediator pattern.
|
|
|
|
|
Pete O'Hanlon wrote: I would definitely take a look into Dependency Injection
I did a search and found Martin Fowler's article on Dependency Injection.[^] Iteresting read.
My situation is similar but not exactly the same to that described in the article, but I think the principle is still applicable, more or less.
Basically, I have one class that offers a set of services, mainly simple notifications when certain things happen within the application. Next, I have a group of class's that use these services. Which services are used can vary from class to class.
The problem I run into is when I start trying to manually wire things up. So I've got my Service over here and my Clients over here, and I have to remember which services a client needs when wiring them together.
The solution that I've settled on is to pass the Service to each Client when it is created. Then the Client can subscribe to those services it needs. The containing class, the one containing all of the Clients, doesn't have to know how to hook up Clients to the Service; it just pass the Service along.
I think I like this solution. It has greater coupling in that Clients are familiar with the Service, but this can be mitigated by hiding the Service behind an interface, which I think is what Dependency Injection does, more or less.
Anyway, thanks for the reply. I'd heard of Dependency Inversion but not Dependency Injection.
|
|
|
|
|
|
I've already seen your article. There's no need to spam it.  And I've done a lot of Dependency Injection, so I don't need a link to an article on it, hence the reason I recommended it.
|
|
|
|
|
Pete,
May be I was not very clear . Actually not only I agreed with your opinion, but I meant to add into your concise reply by informing Lelie who wrote "I'd heard of Dependency Inversion but not Dependency Injection", that is why I referred to a link! Perhaps it was"Inversion of Control"  that was intended.
Fakher Halim
modified on Thursday, July 17, 2008 4:00 PM
|
|
|
|
|
Fakher Halim wrote: Perhaps you meant "Inversion of Control"
Nope - I meant Dependency Injection, as featured in my original post, and which he found in his search. Anyway, no harm done.
|
|
|
|
|
Thanks!! it should be just a typo! 
Fakher Halim
|
|
|
|
|
Pete O'Hanlon wrote: BTW - what you described initially sounds to me like a variation on the Mediator pattern.
You mean this initial statement?
Leslie Sanford wrote: I was reading
led mike
|
|
|
|
|
led mike wrote: You mean this initial statement?
Leslie Sanford wrote:
I was reading
|
|
|
|
|
Good morning!!
What's the design pattern whereby you have to go through a certain class to get an instance of another?
E.G,
I have a class called Devices, and classes Valve, PID, ControlVlv and Pump.
I don't want to be able to instantiate Valve, Pump etc without going through Devices (which will return a collection of said classes).
But I want to be able to use said classes throughout the app.
Does that make sense?
I'm sure I've done it before....
Thanks,
|
|
|
|
|
Hi,
sounds like a Factory to me.
|
|
|
|
|
Ye ah I thought that, just can't seem to find the right one!
|
|
|
|
|
You've got the right surname to be talking about patterns.  Sounds like you need to consider using something like the Abstract Factory pattern.
|
|
|
|
|
This one has puzzled me before.
Valves, pumps, and the like sound very concrete, yet they want to call it an abstract factory?
|
|
|
|
|
I know. It's a really crappy name. Really really crappy.
|
|
|
|
|
|
Nooooo. It is a good name, though just as good and maybe better would be static factory. The factory itself is usually a class with only static methods, so it should be static (or abstract, though static is perhaps the more academically pleasing choice since it's not intended as a base class for concrete factories but rather just a bunch of static members relating to the same thing). So even though the products of the factory are concrete, the factory itself isn't.
Pump p = Factory.CreatePump(...);
not
Factory f = new Factory();
Pump p = f.CreatePump(...);
Normalement.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
