• 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

Client view object

 
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Folks -
Is it overkill to use view objects for the client to display data? For example, when displaying flight data for a chosen flight the sequence goes like this:
Controller --> Facade.find() --> DataAccess.criteriaFind --> Data.criteriaFind()
Data returns a DataInfo[]
DataAccess returns a DataInfo[]
Facade then converts the DataInfo[] into String[] and returns String[] to the Controller.
Controller then creates a BookFlightPanel passing the String[] into the constructor.
I'm thinking about using a view object instead of the String[].
I'm wondering if anybody thinks this is overkill.
 
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
String[] should be enough. No need to create any business or view objects.
 
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My sequence:
Controller -> Facade.find -> Proxy.criteriaFind -> Server.criteriaFind* -> Data.criteriaFind
* skipped in local model
Data returns a DataInfo[]
Server/Proxy return a DataInfo[]
Facade then converts the DataInfo into Flight object and returns Flight[] to the Controller
The controller sends the Flight list to the view, which through custom TableModel and CellRenderers shows the Flight[]
Flight in not a view object but a model one.
I don't know if it's overkill. It's simply the way I feel comfortable with.
 
Sai Prasad
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Now you have a table model which can be used only to display Flight(s). Why not create a reusable table model which deals with Object[][]?
 
Eduard Jodas
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In fact, I have a View that deals with Flight(s), not a TableModel. The Flight is a Bean, so it fires property change events if data changes. This way whenever a flight changes (i.e. seats booked) the view is automatically updated. In the future, if the application is modified to add functionality such as fligh information maintennance, the SearchResultsPanel doesn't need to be changed.
The View has internally a TableModel, but the facade doesn't worry about it. The View performs the translation between Flight[] and TableModel
Furthermore, the DefaultTableModel already deals with Object[][]. No need to have a new one.
 
Sai Prasad
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is no requirement to update the view based on changes to flight data which was not initiated by the user. So why bother creating PropertyChangeEvent(s)? User initiates the search or book flights action and you take care of it by the controller. The controller knows when to update the view and not the other way around. I also recommend keeping the table model in the controller. I wouldn't use the Flight data object which I think is unnecessay. It is easy to translate between the DataInfo and Object[] in the controller.
 
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Each to his own when it comes to storing your objects.
For me, my facade business methods return generic Collection types. It makes it easier to change down the road for whatever reason.
For example, after I had developed my GUI, I realized that I would like the Origin and Destination values in my search form to be alphabetized. Since I had use generic Collection return types, I was able to simply change my Collection from HashSet to TreeSet, and boom, alphabetized choices.
Gotta love that polymorphism.
 
BJ Grau
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
For anyone following this thread, let me clarify my original sequence. I had my brain turned off when I made my original post. What I am actually doing is getting one record, the flight that I am interested in booking. I'm not locking the record yet, just displaying it by itself on a BookFlightPanel that allows the user to enter the numebr of seats requested.

It really goes like this:
Controller --> Facade.getFlightForBooking() --> DataAccess.find() --> Data.find()
Data.find() returns DataInfo
DataAccess.find() returns DataInfo
Facade.getFlightForBooking returns String[]
DataAccess can be either an instance of DataAccessLcoal or DataAccessRemote, but the Facade never knows which.
 
Sai Prasad
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I kind of understood your question! The problem with your design is that you need to take care of mapping the DataInfo to String[] and then the String[] to view component values. I suggest map the DataInfo directly to the screen component values with out the intermediary String[].
[ June 17, 2002: Message edited by: Sai Prasad ]
 
BJ Grau
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So what are you suggesting? I sure you're not suggesting passing DataInfo into the Panel. Perhaps passing separate Strings into the Panel?
 
Sai Prasad
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Read the DataInfo in the Controller and call appropriate setXXXX() methods defined in the JFrame or JPanel (depending on your design) to populate the view.
 
BJ Grau
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think there should be some separation between layers that will allow you to, for example, change the database implementation without having to touch other parts of the application. If you are passing a DataInfo to the controller, you are not providing much separation. I think the database-specific classes should not go past the DataAccess or Facade. I would like to cut them off at the DataAccess but it is fitting my design better to make the Facade the cutoff point.
 
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree BJ - especially here where we KNOW the data interface is going to change with future refactorings. How do we know? There will be a necessity for multiple tables at some point - that will drive the need for indexing. That will drive a different interface, probably more SQL-like. And we'll want to can the passing of all of these Strings that need to be parsed. Probably we'll end up with Select objects, Where objects, Update object and the like. Your DOA should be the only client side piece that should be effected by these refactorings.
Further, we should structure our current client side piece, into two distinct layers, so that at some point, a server side layer that handles all of the business logic, can be easily separated from a client piece that only know how to render itself. These a reason the whole world has gone to thin client since this test was devised, and we should be prepared for this migration in our project too.
 
Kirk Maze
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A lower thread reminds me of one other way we KNOW the Data interface is going to change at some point - there is absolutely no reason for the business logic server or especially the client, to have any knowlege about lock/unlock. Lock/unlocke is a purely internal houskeeping function of the db server. The user of the db server should simply be able to assume that the records are being locked and unlocked appropriately when they ask for or submit records. Most of us are moving in that direction with a LockManager, at some point the project will go the rest of the way and delete the lock and unlock from the published interface.
 
BJ Grau
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is a tough decision. I know folks who have gotten great scores passing DataInfo directly into the Panel and having the Panel populate itself.
Along the same lines, I am hearing Sai suggest handing DataInfo to the controller to populate the Panel with.
It is so hard for me to consider passing a data layer object into the controller, but maybe I am over-designing here. I'm real curious to know what Mark, Peter, and other people think.
 
Sai Prasad
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
BJ,
I didn't have a Facade object in my design. So I had to map the DataInfo in the controller. I believe the design should include either the Controller or Facade. It is as easy to change the Controller in the future as the Facade.
 
Eduard Jodas
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
BJ,
the more layered your desing is the longer the assignment will take, but the easier its maintennance will be.
The less layered -> the faster development (at least in a little project like SCJD assignment with no changing requirements), but the harder to maintain.
What is best? in my opinion it depends on the future work made on the assignment, something we don't really know (and won't ever know), and the need of the company to have a program working asap, something we don't know either.
Make your assumptions and go on. The more time you hesitate the more time you waste for nothing.
Why I chose a more layered approach than maybe Sai? Well, I can only work on the assignment some weekends, and that way is difficult to keep the overall design in mind. I've been trying to keep the design close to what I'm doing in my real job, to help me remember. I won't write that in my decisions document, though. Hope there aren't Sun's spies round here.
Things like puting the TableModel in the Controller or in the View are not important. Follow your way, create your own style. If at the end of the project you don't like it, change it next time. But at least you'll have something working.
reply
    Bookmark Topic Watch Topic
  • New Topic