Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

URlyBird 1.2.2 Design Issue

 
R van Vliet
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi there,

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
 
Alex Belisle Turcot
Ranch Hand
Posts: 516
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm having the same thoughts right now...

I use cachedRecord inside my Data class, and then return arrays of Strings.
Fine, to me that is how my Data structure works internally and the rest of my code doesn't know about it.

Then, I think I will create a higher level of "Record" abstraction (no isDeleted, isMatching.. methods).

I like to think of my Data as a library, and its implementation and whatever its using is hidden to me (the low-level Record object).

I'll be glad to debate that with you
 
John Stone
Ranch Hand
Posts: 332
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic