• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Reading the schema

 
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi!

I've got the B&S assignment.

The design decision I have been pondering on, and would like to hear your opinions on is reading the schema of the data file.

Unfortunately the schema does not describe whether different data-types are currency, strings, numbers etc. It can be deduced by using common sense by the programmer obviously. But if I add things like search for more than, or less than this number of employees or this cost etc, I am hardcoding that data-type... That means that if there is a schema update server side, ALL clients have to be re-coded... Yiuk!

... How did you guys justify this decision and what did you decide=?

Thanks /Dave
 
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've used a two-tiered approach, first validating whether the datafile is well-formed, then validating whether the record contents are as expected. The second layer relies on object inheritence to establish a "plugin" structure, keeping the datafile reader completely generic.
 
David Abramowicz
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Perhaps I didn't ask the question with enough accuracy...

Validating the data according to the schema I have no issues with.

It is how I display the GUI to reflect the schema dynamically I believe is difficult. Either I hardcode the GUI, in which case my problem of how to display different search option for different kinds of data types etc is solved... But will result in a client "re-code" if there is a schema update. This is not desirable.

Or I generate the GUI completely dynamically.... In which case it I can't assume that the data-type "no of employees" is a number and "rate" is a currency and therefoer also a number etc... Making searching more difficult.

.... Hmm... I know what I mean

/Dave
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi David,

My personal choice was to use a ValueObject to represent a record from the database. The fields within the ValueObject could then be referenced as the original field type (String) or as my interpreted field type. My reasoning was that if the field type definition changed at the database level, I would only need to change how to construct my ValueObject using that new field type - the classes which used the value object would still use the same getters.

I constructed my ValueObjects in the model of my MVC, mainly because of my belief that the instructions require the business logic to be client side (I can point you to a huge discussion on that if you are interested). Similar logic to why I am used a ValueObject in the first place: if the method of connecting to the database / getting the raw data changed, I would only need to change the model of the MVC (which is one of the common reasons for using an MVC).

I have seen other candidates returning ValueObjects from business methods in their servers. If you are already doing conversions from String to some other data format within the ValueObject constructor, then if the database field format changes, you only need to change the constructor to handle the new field format.

Regards, Andrew
 
David Abramowicz
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Andrew!

Interesting...

Yes I wouldn't mind having read of the client-or-server-side business logic discussion, if you could point me in the right direction.

Thanks /Dave
 
Andrew Monkhouse
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Dave,

The topic I was referring to is "Should lock methods be callable by the client" - once you make a decision on whether lock methods should be exposed or not, busines methods must logically follow.

Give yourself lots of time to read it

Regards,
 
If you want to look young and thin, hang around old, fat people. Or this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic