Forums Register Login

Client view object

+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
String[] should be enough. No need to create any business or view objects.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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[][]?
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
So what are you suggesting? I sure you're not suggesting passing DataInfo into the Panel. Perhaps passing separate Strings into the Panel?
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
A wop bop a lu bob a womp bam boom. Tutti frutti ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 1043 times.
Similar Threads
Question for Eugene re: push and pull in gui
Business logic
Implementing Lock/Unlock
Final Design Please help
JSTL request.getAttribute(String attName)
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 07:07:11.