This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hey, my assignment is B&S. I would like to know what you implement for client. From my instruction, it says that:
It must allow the user to search the data for all records, or for records where the name and/or location fields exactly match values specified by the user. It must allow the user to book a selected record, updating the database file accordingly.
So I should implement: 1. booking a record 2. search for all record 3. search for name/city 4. update record.
What I am not clear is: what does it mean a booking? what does it mean for update: change the value, delete a record, and/or remove a record? or the booking and updating are related: it only allows update owner information?
Originally posted by Andy Zhu: booking and updating are related: it only allows update owner information?
Yes booking and update are related. update is a database operation book is a business operation that follows the 'unit of work' pattern
book will typically be implemented by calling lock, read, update, unlock on the database. by reading whilst locked you can be sure that no further changes to the record will be made whilst you hold the lock and you can therefore check that what you think you are booking is what you are booking. in the update (I think the assignments are the same in this regard) you will merely assign a customer number to the empty 'owner' field. Your book method should be considerate regarding locking and unlocking especially in the event of any thrown exceptions, there will probably be a finally clause that unlocks before book returns.
SCJP 1.4, SCJD
Joined: May 26, 2004
Thanks. In my business logic, I did lock->read->compare->update->unlock for booking. As you suggest, it seems that only value we can update is actually the owner. I try to confirm that when I compare, I should compare the other fields such as name, city, etc be the same, so that I can be sure that is the same record refered to by the client and server.
However, at this business logic, there should not be a locking involved for searching.
Further, I think I don't need to implement create, delete, and update for other purpose (such as update the size/rate, B&S) at this level. Am I on the way?
Thanks very much.
Joined: Sep 23, 2003
Yes you should ensure it is the same record in every respect the two variations I have are throwing a RecordBookedException which is a subclass of RecordModifiedException which can also be thrown if the record differs in other ways.
Everything else you say, IMHO, is correct.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com