String[] vs. value object

[Anonymous]

Hi,
I just realized that I might have bet on the wrong horse. Would like to know what you fellow ranchers think.
The DBAccess interface of the URLyBird 1.2.1 requires the Data class to return a String[] as the representation of a record. All my higher layers starting at the adapter deal with Room objects instead i.e. the adapter returns a room instead of a String[]. So, Room is my value object. Of course it has got type-specific accessor methods such as Date getDate() or boolean isSmoking() (funny misleading method name btw.).
[Side note]
It is not a business object but rather a value because it's got no business methods - it is a JavaBean in fact.
[/Side note]
Apart from all the good sides this results in a very tight coupling between the schema/data file format and various classes. At the front end even my table model depends (indirectly) on that schema because it stores a collection of Room objects. This results in something like this:

public Object getValueAt(int row, int column) {
    Object value = null;
    Room r = (Room) rooms.get(row);
    switch (column) {
        case 0:
            value = r.getHotel();
...

The fact that I have type-specific accessor methods doesn't make it easier because primitive types (boolean/short) need to be put into their respective wrapper classes. I know reuse is not a key issue here but still...
Should I rather stay with the String[]? I don't like it, but it would allow me to react a lot more flexibly should the schema ever change (column addition/removal). A hybrid-solution would mandate that the Room object is unwrapped before it is put into the model. I don't like that either because wrap/unwrap take time.
I have to be careful not to get overwhelmed with self-criticism...
Regards,
Marcel
[ April 21, 2004: Message edited by: Marcel St�r ]
[ April 21, 2004: Message edited by: Marcel St�r ]

[Mark Spritzler]

Well, we all know Value Objects are great for passing data around in a networked environment. What this does introduce for you is another layer in your design. Your Value Object could have a constructor that takes a String[] as a parameter and turns it into the Value Object. What is wrong with that. Also dealing with Value Objects couples the Value Object, which is fine rather than the Data Access classes. So if later on you want to swap out the Data Access, you can with something different. Your Value Object will always be the same.
Mark

[Anonymous]

Mark,
Thanks for the encouraging reply.
My value object does indeed accept the String[] in the parameter is therefore able to build itself. What I meant is, that once the schema changes (e.g. new column), the value object will have to be modified, too. There's no way around that.
Regards,
Marcel

[Gytis Jakutonis]

Marcel,
I consider value object(together with 3-tier scheme, which is out of the scope in this thread) as quite obvious solution for the assignment, but the following statement brings me down: 'Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs'. So while value object is coupled with business logic and greatly simplifies client side implementation, its main disadvantage is that in iorder to introduce new columns or remove old ones, value object has to be changed, GUI has to be updated, and(this is the main point) client has to upload new code. In real world applications it is quite usuall, but that requirement from Sun does not fit here. IMO it is always easier and less bug prone to refactor non-flexible business code, than to build flexible framework.

[Anonymous]

Gytis,
I totally agree with you. Sun says

...establish a framework...

and

...minimal disruption for the user...

. This raises questions - at least for me it does. Maybe they should be discussed in a new topic?
Should we stay away from the KISS approach and not use MVC (4-5 classes)? They want us to implement a real GUI framework?
I'm not native English but to me "minimal disruption" means that the user should not be confronted with a completly new GUI should the application ever evolve. So, modifications should be built around the same core GUI that we're supposed to develop here.
You said something about "upload new code"...not sure what you mean. Of course, the user would need a new JAR for the new app...
Regards,
Marcel

[Mark Spritzler]

"Should we stay away from the KISS approach "
No, by all means, KISS is what Sun is really looking for, and my motto.

Mark

[Gytis Jakutonis]

Marcel,
there is no need for a client to upload new classes, if server size uses String[] approach and GUI is not coupled with concrete columns. This leads to pure 2-tier approach, something like database management tool like PLSQL Developer. But our GUI still needs business logic(like booking records), and this is the most confusing issue - we need to be flexible and implement concrete business logic at the same time. E.g. if we use String[] approach, we might think that our records can be extended or changed without refactoring the client side, BUT business logic like booking relies on CONCRETE columns, so there is our flexibility?
If we wrap record into value object, then we definetely loose flexibility. One possible solution is to have value object with no predefined columns, smth like map. This approach enables to add/remove columns without refactoring GUI. But it totaly breaks KISS principle.

[Gytis Jakutonis]

Yet another idea just came in: what if Suns GUI 'framework' does not mean some sort of API or library, but just look-and-feel and general GUI structure. In this case 'minimal disruption to the users' may mean that GUI design should be easyly extendable but these extensions should be easy to understand for a user. E.g. menu is easy to extend and tghese extensions do not change whole GUI dramatically, while adding additional functionality to interface with hard-wired set of buttons(not a toolbar) or wizards may be harder(to implement and to accept by usual user). If we treat these requiremens like this, we can ge with 2-tier or 3-tier, String[] or value object(at least with this requirement). It would be very interesting to hear comments on this topic from developers, who passed the exam with value object or 3-tier architecture(as Ken Kerbs). Thanks.

[Anonymous]

Gytis,
I'll stick with 3-tier and value object - and I do intend to pass
Regards,
Marcel

[Javini Javono]

Hi,
Here is my two-cents on one or more issues raised in this thread, though
I am not an expert. Sometimes my remarks may not necessarily be an
"answer" but simply further discussion or questions.
Let it be assumed that the only user interface of interest for my comment
or comments that follow deals with the booking interface.
The booking interface allows the end-user to mutate one field.
The booking interface allows the end-user to search for bookable records.
If the logic is on the server such that the end-user client application can
be a dumb as possible, then all the end-user client application has to do
is display the data, and allow the end-user to mutate one field.
From the end-user client application's perspective, what the "meaning"
of a given field is in not relevant (the only thing relevant is displaying
an appropriate column header in the JTable). The end-user application's
user interface simply needs to be told what database type it is displaying
(URLy Bird or Book Rental, for example), and which column is mutable,
and what allowable values are allowed in the mutable field.
Thus, I am inclined to consider a search and listing mechanism on the
server such that there is very little end-user application thinking involved.
For example, the search algorithm would take into account the 48-hour rule.
This suggests a pseudo-framework approach, wherein the database is
defined so that its behavior can be modified by rules. Thus, for one type
of database, such as URLy Bird, I might say that column "date", will have
special, server-side rules associated with it with regards to searching--
sort of like stored-procedures, perhaps.
Theoretically, one could define searching rules for
1. A given database type,
2. A given column within a row of that database type.
The one difficulty, perhaps, is that the searching algorithm might become
overly complex or bloated.
The one advantage is that the client becomes relatively context-free when
displaying the booking user-interface; it doesn't have any need to know
what any particular column "means". Thus, methods like getHotel() have
no function, and thus no need to be written (though, again, you might
still use a value-like object, so that it is smart enough to determine what
items within it get mapped to which columns within the JTable).
I'm not saying that I am going in this direction, only that I am considering
it. (Or maybe I have gone in this direction to some extent, but need to
review my code to see what I have done).
Thanks,
Javini Javono

[Philippe Maquet]

Hi Javini,
I like your idea to put some abstraction in the way the client handles data.
OOH it goes in the right direction as far as the flexibility required for the GUI in the instructions is concerned, and OTOH it's possible to make the GUI flexible without breaking the KISS principle.
A String[] is flexible (and extensible) by definition. The only thing we need is a bit of meta-information about it. Not the metadata we find in the file header, but meta-information on the String[] passed to the GUI for display, in order to make the client able to handle records in an abstract way (e.g. for each field: the column header, its type, if it must be displayed or not, etc., and globally maybe their display order). This require only one more method implemented server-side and only one method call client-side at startup. Flexible enough and still simple I think.
Regards,
Phil.

[Zafer Abu saeed]

Philippe and Javini;
could you please explain the suggested design with more details and code if possible.
I was attempting to abstract the record as (String[] and MetaData), then I realized that the "meaning" of a column should be understood by the code.
example:
Suppose that I want to use a comboBox that contains all possible values of the "location" column in order to implement Search, then how can I populate this comboBox if I don't know that this is a "location" column ?

[Anonymous]

Javini,
I must admit that I didn't quite get the idea. Phil obviously did... I'd be happy if either of you could elaborate on this a little more. I have to say, though, that I like the idea of using metadata to give a generic type some context. On the other hand I still like the value object approach.
My value object "Room" now has a toArray() method which returns an Object array including all data and the primary key. I thought String[] was a bit too specific. So, the db adapter/facade fetches a record (i.e. String[]) and passes it to the Room's constructor. The db adapter then returns a List of Room objects. The client can handle them the way it likes; either as a value objet or as an Object[].
In my situation, the table model now uses the Object[], which simplifies the implementation of getValueAt() and setValueAt() quite a bit. However, the client still needs to know the types of all the values stores inside the Object[]. At the moment there's hardcoded array of types (e.g. String.class) inside the table model. Javini's or Phil's approach could come to rescue here...if I only understood it.
Regards,
Marcel

[Philippe Maquet]

Hi Marcel,
It's the middle of the day here and I cannot elaborate in 5'. But I'll reply tonight (Brussels time). It looks like I've a few pending threads to step in...
Regards,
Phil.

[Philippe Maquet]

Hi Marcel,
I didn't think of any specific solution but of a principle.
The following excerpt of the instructions:

Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs.

lets me think that the least we "hardcode" in the client and the most abstraction we put in it (while still keeping things *simple* ), the best it is.
The idea is that each time you feel hardcoding compelling, you ask yourself: "What's the information I'd need now to avoid hardcoding?".
Examples:
- Do you allow searching on name and location (hardcoded at two levels BTW: exactly *2* fields AND (name + location))? Or do you allow searching on *some* combination of *any* field, as a result of some properties queried from the server?
- Do you display the "smoking" field as a boolean because it's the "smoking" field? Or do you display it as a boolean because the server informs you of the field types?
Just make an inventory of all client config information you need from the server to avoid as much hardcoding as *you* want. Then design a class aimed to carry that information from the server to the client (some "config" value object). And write a remote method that any client will call at startup.
If you take care, it should be possible to change the fields a CSR is able to search on and/or even the data file format without any need to change the client code, leading to ... "minimal disruption to the users when this occurs" (just a restart of the unchanged client applications at the worse).
Of course, this works better with a 3-tiers design...
Regards,
Phil.

[Gytis Jakutonis]

Hi Philippe,
I kind of disagree with those meta-data approaches. My arguments are based on assignment requirements(and as professional developers we always need to stick with requirements instead of developing solution for all cases, because we can run out of budget ):
1. application will not be reused in future
2. application is basically for learning purposes
3. GUI flexibility(as you have mentioned) indirectly requires MVC, which has nothing to do with flexible meta-data approach
4. simplicity is the main target, not the flexbility
Business logic always is tightly coupled with concrete business data, i.e. database is just a tool to build business logic and not vice versa. Take any business implementation - how often do you parse oracle schema to determine columns, their types and sizes? Usually you use oracle table and expect it to have all columns you need with all configuration(size and type) you have implemented in business tier.
And one more note - we can use meta data at business level, but it is quite difficult to have flexible client side. Consider following situation - your client reads meta data and uses it to dusplay JTable and search dialog. You change meta data on server side and expect to see new columns in JTable or search screen. It is possible and not so hard to implement. But how about descriptive column names? You may include them into meta data, but then another issue comes out - how about localization? You need to supply either localized(by client locale) meta data or meta data with many localized strings. One more level of complexibility - and look at 1-4 arguments once again.
So I'm very interested to hear any comment on this issue from developers, who succeeded with hardcoded business logic without all meta data mess. I think Ken Kerbs had smth like this, hadn't he? Others?

[Philippe Maquet]

Hi Gytis,

My arguments are based on assignment requirements (...)
1. application will not be reused in future
2. application is basically for learning purposes
3. GUI flexibility(as you have mentioned) indirectly requires MVC, which has nothing to do with flexible meta-data approach
4. simplicity is the main target, not the flexbility

1. "application will not be reused in future": isn't it a free interpration of yours? The exact wording is "The IT director does not anticipate *much* reuse of the first Java technology system". But under the GUI section, it's also stated that "Your user interface should be designed with the expectation of future functionality enhancements,". How would you expect "functionality enhancements" in an application which would be supposed to not be reused at all?
2. "application is basically for learning purposes". Yes. "(The IT Director) intends to use that system as a learning exercise before going on to a web based system.". But cannot building a flexible GUI be part of the learning process?
3. I don't see any contradiction.
4. "simplicity is the main target, not the flexbility". Simplicity is not opposed to flexiblity IMO, and both are expected in our application. BTW, did I suggest anything *difficult* in my previous post?
Regards,
Phil.

[Gytis Jakutonis]

Philippe,
IMO to support GUI flexibility we should use MVC. But MVC can be used without meta-data structures. As for simplicity vs. flexibility, I think that meta-data approach with field size, type and other information is quite complex. I want to ask once again - how often you build application by parsing oracle(or other rdbms) schemas? How often you use meta-data for business logic?

[Tobias Nettels]

IMHO the main disadvantage of shifting metadata from the data layer to the view is that the data tier then has to think about how this data could be used or viewed. This is not the data layers work but the views. The data layer would not mind if i.e. the field size in a table header of the view is labeled 'total size' or 'available size' or just 'size' or what ever - its on the view to display and label this field. Therefore its justifiable (and common in praxis i think) to hardcode this information in the view.

[Philippe Maquet]

Hi Gytis and Tobias,
It looks like we simply misunderstood us. You both insist about the Presentation layer (View) having not to care about the Data layer, and I cannot disagree with you about that. But it's not my point. Everything I wrote above was with a 3-layers design in mind (I didn't write "tiers" (physical connotation) on purpose - no need IMO to reopen that *huge* number-of-tiers discussion ), and was in favour of the maximum *decoupling* between Data and Presentation.
Anyway, I don't try to *convince* anybody about it, and ... I must confess that I now feel short of arguments (or too tired tonight to argue further)...
Regards,
Phil.
[ April 30, 2004: Message edited by: Philippe Maquet ]

[Gytis Jakutonis]

Hi Philippe,
I do not want to discuss about 2 vs. 3-tiers(since I've already made my desicion). But even with 2-tier approach there is business logic sitting somewhere(in MVC controller or smth like that). I point is that in this (and many similar) project we do not need to support flexibility in business logic. Business logic expects database to have some structure, and not vice versa. Business logic itself may define that structure in properties file or as hardcoded constants, so that presentation tier does not need to hardcode all field sizes etc.:
Database[Fields] <---uses--- Business[Schema] <---uses--- Presentation
So database fields does not affect business schema, they are used by to store schema information.

[Philippe Maquet]

Hi Gytis,

Business logic expects database to have some structure, and not vice versa. Business logic itself may define that structure in properties file or as hardcoded constants, so that presentation tier does not need to hardcode all field sizes etc.:
Database[Fields] <---uses--- Business[Schema] <---uses--- Presentation

I fully agree with you. But when your business logic resides server-side (as in my own design), it makes sense to manage it server-side as much as possible, right? IMO, it's a key point to meet the following requirement for the client GUI: "minimal disruption to the users".
Regards,
Phil.

[Gytis Jakutonis]

Philippe,
seems like we are quite close to reach agreement . We can try to make business tier very flexible, but at some point presentation tier will be coupled with concrete business logic(presentation tier purpose is to provide business logic for customer, isn't it?). In our case one coupling comes with 'client id'(owner) field for booking - presentation tier relies on business logic to have that field and we have to accept this fact.
As for requirement you've mentioned in the last post - I was concerned about this one, but finally I've reached conclusion that this requirement is for GUI(as it is from GUI description) and is related with MVC pattern, and not with business-presentation tier flexibility. I have several arguments on this.