Databases
StackOverflow2013
Postsdbo
POMessage passing in a plug-in framework
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POMessage passing in a plug-in framework
    primarykey
    data
    text
    <p>First off, there's a bit of background to this issue available on my blog:</p> <ul> <li><a href="http://www.codebork.com/coding/2008/06/25/message-passing-a-plug-framework.html" rel="nofollow noreferrer">http://www.codebork.com/coding/2008/06/25/message-passing-a-plug-framework.html</a></li> <li><a href="http://www.codebork.com/coding/2008/07/31/message-passing-2.html" rel="nofollow noreferrer">http://www.codebork.com/coding/2008/07/31/message-passing-2.html</a> </li> </ul> <p>I'm aware that the descriptions aren't hugely clear, so I'll try to summarise what I'm attempting as best I can here. The application is a personal finance program. Further background on the framework itself is available at the end of this post.</p> <p>There are a number of different types of plug-in that the framework can handle (e.g., accounts, export, reporting, etc.). However, I'm focussing on one particular class of plug-in, so-called data plug-ins, as it is this class that is causing me problems. I have one class of data plug-in for accounts, one for transactions, etc.</p> <p>I'm midway through a vast re-factoring that has left me with the following architecture for data plug-ins:</p> <ul> <li>The data plug-in object (implementing intialisation, installation and plug-in metadata) [implements <code>IDataPlugin&lt;FactoryType&gt;</code>] </li> <li>The data object (such as an account) [implements, e.g., <code>IAccount</code>] </li> <li>A factory to create instances of the data object [implements, e.g., <code>IAccountFactory</code>]</li> </ul> <p>Previously the data object and the plug-in object were combined into one, but this meant that a new transaction plug-in had to be instantiated for each transaction recorded in the account which caused a number of problems. Unfortunately, that re-factoring has broken my message passing. The data object implements <code>INotifyPropertyChanged</code>, and so I've hit a new problem, and one that I'm not sure how to work around: the plug-in object is registering events with the message broker, but it's the data objects that actually fire the events. This means that <strong>the subscribing plug-in currently has to subscribe to each created account, transaction, etc.!</strong> This is clearly not scalable. </p> <p>As far as I can tell at the moment I have two possible solutions:</p> <ol> <li>Make the data plug-in object a go-between for the data-objects and message broker, possibly batching change notifications. I don't like this because it adds another layer of complexity to the messaging system that I feel I should be able to do without. </li> <li>Junk the current event-based implementation and use something else that's more easily manageable (in-memory WCF?!).</li> </ol> <p>So I guess I'm really asking: </p> <ol> <li>How would you solve this problem?</li> <li>What potential solutions do you think I've overlooked?</li> <li>Is my approach even vaguely on-track/sensible?! :-)</li> </ol> <p>As you will be able to tell from the dates of the blog posts, some variant of this problem has been taxing me for quite a long time now! As such, any and all responses will be greatly appreciated. </p> <p>The background to the framework itself is as follows: </p> <blockquote> <p>My plug-in framework consists of three main components: a plug-in broker, a preferences manager and a message broker. The plug-in broker does the bread-and-butter plug-in stuff: discovering and creating plug-ins. The preferences manager manages user preferences for the framework and individual plug-ins, such as which plug-ins are enabled, where data should be saved, etc. Communication is via publish/subscribe, with the message broker sitting in the middle, gathering all published message types and managing subscriptions. The publish/subscribe is currently implemented via the .NET <code>INotifyPropertyChanged</code> interface, which provides one event called <code>PropertyChanged</code>; the message broker builds a list of all plug-ins implementing <code>INotifyPropertyChanged</code> and subscribes other plug-ins this event. The purpose of the message passing is to allow the account and transaction plug-ins to notify the storage plug-ins that data has changed so that it may be saved. </p> </blockquote>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USThinkingStiff
    1. USalastairs
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POMessage passing in a plug-in framework
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POMessage passing in a plug-in framework
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POMessage passing in a plug-in framework
      1. USYoussef
      1. VTFavorite
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload