Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

FBN: Which classes in which package?

 
Laura Alex
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I've listed some of my classes and interfaces for the FBN application. I'm not sure which package to put the LocalDataAccess and RemoteDataAccess in.
client
-------
Controller - the controller in MVC pattern. Retrieves database access by
calling DataAccessFactory which always returns an instance of type DataAccess regardless of the mode the app is running in.
DataAccessFactory - creates a connection to database access an returns
a DataAccess which can be either a LocalDataAccess or RemoteDataAccess depending on if the user is running the application locally or network.
LocalDataAccess implements DataAccess - has all the same public methods as Data, used to access the database when the applicaiton is running locally.

db
-------
interface DataAccess extends Remote - has all the public methods of Data
Data

remote
-------
interface ConnectionFactory extends Remote
ConnectionFactoryImpl extends UnicastRemoteObject implements ConnectionFactory - creates a database handle and returns a DataAccess instance which is of type RemoteDataAccess
Server - creates a ConnectionFactory instance and binds it.
RemoteDataAccess extends UnicastRemoteObject implements DataAccess, Unreferenced - has all the same public methods as Data, used to access the
database when the applicaiton is running in network mode.
My question:
I've decided to have my LocalDataAccess class in my Client package in order to meet the requirement of having all the public methods of Data in the client. By having LocalDataAccess in the client I can keep my Controller class fairly clean by only having to declare the methods that are really used right now.
Does this explanation make it ok to have LocalDataAccess in the Client package or does it only belong to the db package because it's about database access?
The same goes for RemoteDataAccess which I figured would do just fine together with my other remote classes and interfaces instead of having it in Data.
Any comments to my design, feel free to post them
Thanks!
/Laura
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Laura,
Originally posted by Laura Alex:
I've decided to have my LocalDataAccess class in my Client package in order to meet the requirement of having all the public methods of Data in the client.

Hmmm, I'm not familiar with that requirement (but then we have different assignments, mine is B&S). I think most people have understood the assignment instructions to require that all the public methods of Data be implemented, but not necessarily made available to the client. If you buy this argument then I think it follows that LocalDataAccess probably belongs in the db package since as you say it's about database access. Even if I were making all the public Data methods available to the client, I would still keep the LocalDataAccess class in the db package. Under those circumstances the Controller class in client would make available all the public Data methods.
It seems natural to me to put the RemoteDataAccess class in the remote package as you suggest rather than in the db package.
I didn't see any problem with the design which is why I limited my comments to the placement of the interfaces into packages.
Hope this helps,
George
 
Laura Alex
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi George,
Thanks for your reply! I went back and looked at my requirements from Sun, it's as follows:
"To connect with your server, you should create a client program. This implementation should include a class that implements the same public methods as the suncertify.db.Data class, although it will need different constructors to allow it to support the network configuration."
The sentence above is the one that I was referring to and the reason why I wanted to keep LocalDataAccess in my Client package. However, I also consider that it belongs to the db package.
I found it interesting though that you think I should leave my RemoteDataAccess in my Server package. RemoteDataAccess implements all the public methods of Data, which LocalDataAccess does as well, and I guess
belongs as much in the db package as my LocalDataAccess class does. How come you think I should keep the RemoteDataAccess class in my Remote package?
I really appreciate your feedback!
/Laura
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Laura,
Given your assignment instructions (which do appear to be different from mine, at least on this point) I think you were right to locate the LocalDataAccess class in the client package.
My reasoning for keeping RemoteDataAccess in the server package is that it really only supports the database when it's accessed remotely as it will be when the application is running in server mode. (So, yes I could have applied the same reasoning to the LocalDataAccess class which really only supports the database when it's accessed locally as it will be when the client is running in standalone mode. )
So clearly the Data class (as the implementor of DataAccess) should be in the db package, while it is perfectly justified to put LocalDataAccess and RemoteDataAccess classes in the packages they support.
My assignment instructions didn't have the requirement to put a class in the client package that implements all the public methods of Data. and so I was able to have the client use a class from the db package directly rather than have a class such as LocalDataAccess in the client package. My packaging architecture would not have been appropriate for your assignment instructions.
Hope this helps,
George
 
Ken Krebs
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Laura,
It looks like your requirements are stating some thing new:
To connect with your server, you should create a client program. This implementation should include a class that implements the same public methods as the suncertify.db.Data class, although it will need different constructors to allow it to support the network configuration.

There has been much discussion of 2-tier vs. 3-tier approaches to the assignment, most notably in Should lock methods be callable by the client. This statement seems to imply that a 2-tiered approach is now required.
To clarify things, could you post a bit more of the surrounding context of this statement ?
Thanks
 
Laura Alex
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Thanks for your answer again George. I'll leave my LocalDataAccess in my Client package and my RemoteDataAccess in my Remote package. Thanks for discussing this with me
Ken, remember that I have the Fly By Night assignment so I believe most people in this forum have a later assignment and therefore different requirements. However, here's the total piece from my instructions from Sun:
"Writing Data Client
To connect with your server, you should create a client program. This implementation should include a class that implements the same public methods as the suncertify.db.Data class, although it will need different constructors to allow it to support the network configuration."
/Laura
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Laura,
When you say

Server - creates a ConnectionFactory instance and binds it.

I take it, using my toy server, and disregarding classes and
interfaces, that you mean method code comparable
to this:

right?
So, the above similar code goes within your ConnectionFactory.
Your server makes the connectionFactory available to the client
as a remote object, and the client says:

In my comparable toy client/server, the client says:

So, I take it that your connectionFactory.getDataAccess()-like
method essentially does the Naming.lookup() call?
What are the benefits to the ConnectionFactory object? I've
seen the term pop-up in a couple threads recently. Is the
advantage that in my toy client/server example, the use of the
String "Dog006" never need be known by the client, it is abstracted away
and handled automatically, so that all the client need supply
is the url?
And, as far as the ConnectionFactory being bound, the Server
will have that binding String hard-coded (so the client won't
need that either). However, you could just as easily have the
Server hard-code the DataAccess binding String, if this were
the only reason.
So, in short, I don't understand the strategic reason for having
a ConnectionFactory. Could you please explain its purpose?
Thanks,
Javini Javono
[ January 29, 2004: Message edited by: Javini Javono ]
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12012
218
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Javini,
So, in short, I don't understand the strategic reason for having
a ConnectionFactory. Could you please explain its purpose?

A connection factory will create a unique connection object for each connected client. Advantages:
  • It is easier to ensure that your server is thread safe.
    Since each thread will be working on a unique object, it does not have to worry about other threads interacting, which means that you should only have to worry about making one or two classes thread safe instead of the entire server.
  • Since your connection is dedicated to a particular client, it could store stateful information (it probably won't for this assignment though).
  • Since you now have a unique object on the server for each connected client, you now have a way of cleaning up if the client disconnects / crashes without performing it's own clean up. For example, if you have the client application calling the lock methods directly, then if the client crashes you might want to remove any locks that it owned.


  • Regards, Andrew
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic