can you please answer these questions too?
Joined: Dec 15, 2005
I can answer 2 of your questions.
3) why did you choose to have a separate business layer? what functionality did you put in there?
Separate business layer encapsulated operations in my data class.
the data class was never shown to client, all client could see was a business interface.
here is the business interface [or server interface]
i hope things can be clearer by looking at this. do reply in case of doubts.
4) how does your gui look like? Did you implement observer pattern?
my gui code was mvc.
a table model encaplsulated my data class.
there was a listener for every type of action. ie Search, Update, Add, Delete.
I used a singleton facade class to access all the current variable set in client.
Joined: Dec 06, 2006
I do use a separate interface to expose the data instances to the clients too. I would never call it "business layer".
4) it is kind of obvious what to code in gui part. I was curious about how the gui looks like. Where did you place your buttons, table, fields? Did you use a context menu? Did you allow sorting, moving columns? Did you use filtering? and so on
Thank you very much for the explanation.
Joined: Dec 15, 2005
gui had following components.
a menubar containing all the global functions with shortcuts.
a table in the middle. a popup menu for the table [Book/unBook Room]
searchpanel at the bottom.
the panel contained 2 labeled editable comboboxes.
1. to search hotel names
2. to search city names.
above to comboboxes suggested current hotel names and city names.
the panel also had a checkbox saying "show the rooms in avaiable in 48 next hours only."
each one of the above components was provided with search action listener. thus any action here would result in change in table rows.
there was no search button.
rest of the functions resided in menubar.
the functions were Create Record, Delete Record, BooK/UnBook Record [Redundant], Settings, About etc.
at the very bottom there was status bar. it dispayed status of previous action ie "Succeeded/Failed" with additional description
apart from this main window. there were extensions of dialog boxes which helped specify properties.
eg "Add new Record Dialog" or "Settings Dialog"
all the ui components refered global variables [as described in previous post].
there was Registry which held record numbers of currently locked records.
when new recordnumber was added to registry, a new lock was created and assigned to record number.
if the recordnumber was already present in registry, the thread would wait on lock assigned to the record number.
when the lock was removed. waiting thread would create new lock.