I'm running into a slight design issue with URLyBird 1.2.2, or at least I feel I'm having to go with a sub optimal approach :
The DBAccess interface, and thus the Data class the instructions tell you to implement use string arrays for record data. My planned design was as follows :
FileDatabase -> Data (DBAccess) -> some room management facade class
Apart from the file database class Data would also have a seperate lock manager to implement the required locking mechanism.
Now, the issue is that initially i made a Room "entity" class to represent a single record to be used throughout the application. But because the DBAccess interface forces string arrays as records it'd be odd to have the FileDatabase class work with Room objects, then convert them to string arrays for the Data end of things, and then right back to Room objects for the facade.
Basically it seems as if the instructions are intended to make you deal with String arrays as the representation for record data throughout the application.
Is this intended you think? And if not how did other people solve this design issue?
Any thoughts or input would be much appreciated, and my apologies for the lengthy and perhaps slightly incoherent post
I had B&S, but the issue was the same. I used String in db layer - Data -> DBFlatFile. I created Contractor class, capable of converting String to Contractor and vice-versa. And I used Contractor class in all other parts of app. I assumed, that Data interface should be the main interface for db layer and that db layer should be independent - having no idea, whether there are contractors or rooms in db. And then in my business class I made conversions String <-> Contractor.
R van Vliet
posted 12 years ago
hey guys, thanks for replying.
I've decided on the following structure so far (please comment) :
I have a RoomManager interface with just bookRoom and findRooms methods. The client only uses this interface to manipulate and query room records. The records themselves are represented by Room objects.
I have a LocalRoomManager implementation of this interface that uses the Data class (implementing DBAccess ofcourse) as a "database API" as proposed above. I dont see any need to place the file access logic in a seperate class, Data without this would just be a useless extra layer.
To implement the client/server functionality I implement a RemoteRoomManager.
The locking is 100% server-side and thus is hidden from the client. So to recap :
Data Manipulation : Data implementing DBAccess Business Layer : RoomManager using Room value objects.
Does anyone think I should split use a seperate class for the actual database file manipulation (so say, make a RoomFileAccess class that the Data can use internally).