• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

String[] or VO??

 
rinke hoekstra
Ranch Hand
Posts: 152
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It seems natural to create a Value Object class to pass info into the book record of the business layer. This class would typically be called "Room".

However, as the application is doing nothing at all with this Room class except passing it as Value Object (which is of course the definition of a value object), I was wondering: why even bother the hassle, as the DB interface already forces the use of String[]s for the data layer, why not keep to this for the whole application?

Just found 2 old threads on this: here and here.

But there wasn't really a strong conclusion (perhaps that doesn't exist), and there also wasn't an answer from somebody using String[] and having passed with good scores.

So, just wondering if there are any new experiences already. Are there any people using String[]s throughout the whole application, or is everyone creating Room objects?
[ July 20, 2007: Message edited by: rinke hoekstra ]
 
Herman Schelti
Ranch Hand
Posts: 387
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi Rinke,

a use a Value Object, and yes I've called it Room.
It has all the fields from the database-file, plus the recordNumber.

I use it instead of String[] because:
-I find room.getLocation() is MUCH easier to read then data.get(1)
-String[] does not look very Object Oriented to me.

I wrote 2 simple static utility methods to convert between String [] and Room.

Herman
 
Gunnar Bastkowski
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I also would say that you should use a vo.

I think it's worth considering use of the adapter pattern to convert between a string array and your vo.
I don't like static utility methods at all, because they usually increase coupling and cannot be overwritten by subclasses.
But this is also a great matter of taste, because static methods often lead to less code ... but now this becomes off topic ;-)

For the use of VOs I feel like Herman.
 
rinke hoekstra
Ranch Hand
Posts: 152
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
String[] does not look very Object Oriented to me.


Applying an Object Oriented approach just for the sake of applying an Object Oriented approach seems not very convincing to me. But yes, you are right, it is a design which is more clear for the junior programmer - and the advantage is you can also add the record number in the object. Disadvantage is: much more code.

I think in the end the conclusion is: it doesn't matter much. Despite this, everyone seems to be using a Room value object, in stead of String[].
 
Marcelo Camargo
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rinke,

I am using Vo too, and, believe or not, I called it Room...
But, I will explain exactly how I am doing:

I have created a business layer, and an exclusive package for that. This layer is an adapter (adapter pattern) between the DBAccess interface to my new clean and easy to use business interface. The business interface is the one I am exposing via RMI to the clients.

And, this interface exposes only a few methods, and encapsulate a lot of details, making easy to the client to call the business methods.

For example, look at these method signature:

public ArrayList<Room> searchAllRooms() throws BusinessFailureException
The client just need to call the method, without any parameters, and will receive a list of all the record (not deleted). I dont need to create any String array to get the list of all rooms. And it will receive a array list of Rooms, not a list of record numbers...

or this one:

public ArrayList<Room> searchRoomsByCriteria(SearchCriteria criteria) throws IllegalArgumentException, BusinessFailureException;
Look at the parameter: I created an SearchCriteria class, just with the hotel name criteria and city location criteria (2 strings). This way, I dont need to create the String array nether. And, look at the exceptions, are all business exceptions. They are better to understand to the client and BusinessFailureException is a checked exception: the client will have to deal with it, not just ignore some RuntimeException.

I think it is better.
 
Chris Be
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Guys,

I am using String[] throughout and found that this involves mimimum coding. The flexibility is that the String[] can be of any size, so there is no limit on the details I can return.

The string array is passed through the layers:

  • The DB interface returns an int[] of recordNumbers matching given criteria
  • The business layer reads the String[] of data for each recordNum, and appends the recordNum to the String[]. It then adds each record to a String[][] array.
  • The String[][] is already good to go straight into the JTable, the record number can be labelled as a booking reference, or easily hidden from display by providing a Table Header String[] one element short of what the data String[] is.


  • I thought this is so simple, and junior programmers definitely know String[]s, possibly much better than WELL DESIGNED OO objects. This requires no stuffing into VO's and extracting again. Perfect match with the keep-it-simple principle.

    ChrisBe
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic