I am starting a new project that will use LLBL. I am facing the following senario: two (or more) stations will be booking rervations for boat docking bays. If one station books a bay then all reservation stations should be updated immediately (similar to travel agency booking). Whats the best way to go about architecting such a solution...

Hi,

If I were you, I would go with BL in a central server. All workstations work with the BL server for all kind all data activities via Remoting, then you can make this communication two way; the central BL server raise a event each time the data should be updated by the workstations.

omar wrote:

I am starting a new project that will use LLBL. I am facing the following senario: two (or more) stations will be booking rervations for boat docking bays. If one station books a bay then all reservation stations should be updated immediately (similar to travel agency booking). Whats the best way to go about architecting such a solution...

Assuming this is strictly a presentation issue (i.e., you want all other reservation stations' GUIs to be updated immediately) then look into the MVC (Model/View/Controller) pattern. It specialized in solving this kind of problem.

Jeff...

I would go with BL in a central server. All workstations work with the BL server for all kind all data activities via Remoting, then you can make this communication two way; the central BL server raise a event each time the data should be updated by the workstations

I went another route where I implemented a central notification server, This notification serevr (NS) communicates with all registered clients through two-way remoting as follows:

1- I build one MBR derived class in the BL layer (NotifyClient) that has a two-way comunication channel with the notifcation server (for this I am utilizing GenuineChannels that facilitates a broadcast engine). The (NotifyClient) utilizes a singlton instance to broadcast/receive events from the notify server.

2- Sending Client: a BL class (Bill) calls (NotifyClient.SendNotification) to declare its event

3- Receiving Client: BL's (NotifyClient) receives the notification in (ReceiveNotification). It checks the received paramters and as result fires (BillInserted) event

4- Receiving Client: (WriteCheck) subscribes to (NotifyClient)'s (BillInserted) event. In the event handler it fires another event (WriteCheckUpdatePayment)

5- UI: WinForm for the (WriteCheck) subscribes to the (WriteCheckUpdatePayment) event to update UI

If I close the UI form, I notice the memory utilization is NOT released until I terminate the application. I suspect the reason being that (NotifyClient)'s only instance is alive for the duration of the application and as such any object subscribing to any event it raises will NOT be collected by the garbage collector because the garbage collector would assume that there is still an object (NotifyClient.Instance) holding a reference to the (WriteCheck) object.

Is there a better way to architect this scenario or am I breaking some rules here?