Whatever happens on the server:
columns chage their places, new column will be added, columns change their names)
there is only one entry point to be changed on the client: database column names.
It also allows dynamic access to the length of fields to validate requests on client
I know, I could use index instead, but I decided not to use it, since it is terrible
on the client GUI to understand which column is used (E.g.it is much easer to work with
column "location" than #2.). I know, there some advantages of using indexes, but
I decided to avoid them.
Here are interface defined to represent a Record:
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
I didn't reply because as it seems that we have so different views on this subject... To be 100% honest, I am also in a hurry now to finish the GUI parts of the assignment
You seem to have invested in a different way of abstracting records data, while I kept data representation unchanged (record = array of String field values) and chose to invest a bit more in added meta-data functionalities.
With your RecordModel / DBAdatapter I feel like you insert a fourth tier between the first (database) and the second (business). Maybe I missed something, but it brings additional complexity without much benefit IMO.
Just for comparison, I personally regret that you abandoned your idea of concurrent-reads-single-write-locks for simplicity. The job was done, well done, it was just a little more complex than "classical" synch
Why do you have the MetaData as part of your Record?
There are valid reasons for doing this - but just want to see if you have thought of them or not
[And now that I've seen Phil's post, I can also add that the answer to my question could also act as an argument against Phil's idea of leaving everything in String[]s ]
Phil, I want this discussion to be a bit different from others. It is like I offered my design and want to defend your critic. I personally don't like my design and instead of arguing I am much more intersted that somebody presents other deisgn, which is simpler, but provides the client flexibility". I am ready to wait. I don't want to put in the rush with answer. I would be glad to get your personal ideas how it shoulb be done when you have time.
The point is I decided not to book/search methods in adapter.
I am afraid to breach Sun requirements. They say that all database functionality (if not /lock/unlock at least delete/update/read/find/create) must be available over the network. In your design (which I also have at the moment, but will change it) there are only two methods available over network, which is dangerous.
How your Record object that your Business tier passes to client looks like?
you don't need an additional layer to abstract record/field access even if keeping unchanged the record format.
Why do you have ClientProps.CUSTOMER and ClientWindow.CUSTOMER_LABEL? Should the constants be in the same class (probably ClientProps)? Or have I misunderstood the use of ClientProps?
Which assignment have you ? It's different in URLyBird.
But if it's the case for you, it's an argument against your additional tier, right ? Because the db interface is fixed in the assignment.
?They say that all database functionality (if not /lock/unlock at least delete/update/read/find/create) must be available over the network. In your design (which I also have at the moment, but will change it) there are only two methods available over network, which is dangerous.
The following are the "top level" features that must be implemented:
A client program with a graphical user interface that connects to the database
A data access system that provides record locking and a flexible search mechanism
Network server functionality for the database system
Hello,
I have decided to apply 3-tier architecture in my assignment (URLyBird 1.1.1).
I have provided new local and remote interfaces to allow high level access to the database:
public interface DBServer {
public void book(RecordModel record)
throws RecordNotFoundException,
DBConcurrentModificationException,
IOException;
public RecordModel[] find(RecordModel criteria) throws IOException;
public MetaData getMetaData() throws IOException;
}
public interface DBServerRemote extends DBServer, Remote {
}
The interface for database access defined by Sun, which will be available only for local use, because it will be used by implementation of DBServer interface, not the client application:
package suncertify.db;
public interface DB
{
public String[] read(int recNo) throws RecordNotFoundException;
public void update(int recNo, String[] data, long lockCookie)
throws RecordNotFoundException, SecurityException;
public void delete(int recNo, long lockCookie)
throws RecordNotFoundException, SecurityException;
public int[] find(String[] criteria);
public int create(String[] data) throws DuplicateKeyException;
public long lock(int recNo) throws RecordNotFoundException;
public void unlock(int recNo, long cookie)
throws RecordNotFoundException, SecurityException;
}
The only access point to work in network mode will be then DBServerRemote interface, which provides only 3 methods required by the my client application.
There is a following requirement in the assignment:
The following are the "top level" features that must be implemented:
A client program with a graphical user interface that connects to the database
A data access system that provides record locking and a flexible search mechanism
Network server functionality for the database system
My question is:
-if my design satisfies requirement,
-Do I have to provide additionally a Remote interface, whose methods would have the same signatures and functionality as local DB interface, except throwing RemoteException,
since I don't understand what interface do you mean by saying "Network server functionality for the database system ".
The only thing that kept the leeches off of me was this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|