i have problem figuring out how and what classes to put into these three packages that i plan to submit - client, db and server. Because my architecture is based on MVC, i have three sub-packages on the client package. 1) J2se packaging -------------- client package |-- model -> classes that deal with data ( eg. FBNFlight, DataAcessHelper, etc ) |-- view -> classes that deal with GUI ( eg..MainFrame, SplitPane, etc ) |-- controller -> classes that trigger action and classes in the model db package -> Data,DatabaseException,DataFactory,DataInfo,DataInterface,FieldInfo,LocalData,RemoteData server package -> ConnectionFactory, DataConnection, LockManager At the moment, all the classes are located in the packages stated above. Am i putting the classes in the right package or am i missing something over here? And i was thinking too whether is it right for me to put the client's sub-packages into its individual parent related package. Eg putting "model" subpackage under "db" package because model contains all the classes that deal with data. So if i were to put these sub-package related to their parent package name, it would look something like this 2) J2ee packaging --------------- client package | -- view package ( gui classes that are related to client ) db package | -- model package ( model classes that are related to data ) server package | -- controller package ( action, server, lockmanager and connection classes )
Please provide me a pointer because i'm really really confused where to stand on and look at the whole picture...
you don't really need to have subpackages in the client. They can simply be in the client package. Other than that I like your packaging. DataFactory can also be in the server package, but could also be in the db package. It is on the bubble. So maybe someone else has a more opinionated feel for that. Mark
Hi Kruger I prefer the first option. You have one package which has (nearly) everything needed to run the client application. Another package that has (nearly) everything needed to run the server application. And the DB package which has the common code that is not in client or server. Therefore if you only want to run the client application, you only two of the packages. Likewise if you only want to run the server, you only need two of the packages. The second option is nowhere near as clean. From what I can see, it appears that all three packages would be necessary in order to run either the client or the server. In which case, what is the point of having them in separate packages? Regards, Andrew
thx mark and andrew for ur input..really appreciated.... Now i have LocalData and RemoteData that implements DataInterface. Which package should i put these two classes into? Into suncertify.client.model OR suncertify.db package??? Currently i have a FlightServices in suncertity.client.model package and this class is making a call to LocalData or RemoteData's method based on the connection mode. So i thought it would be clean if i put them together but on the other side of me, i think it's not a good way because LocalData and RemoteData are the implementation classes of Data, which are quite related to database.. Can u guide me further?
And last question is, should i provide a service to do a "reservation" for the booking? currently i only have a search and booking services...is that enough ?? thx
Hi Kruger Perhaps you could look at it like this. What does "db" package provide? (My answer: the database itself) What does "server" package provide? (My answer: access to the database) What does "client" package provide? (My answer: the GUI) Work out your own answers for what each package provides. They may match my answers, or you may have different answers. (You are going to need to work this out anyway, in order to write your package.html file for each package.) Then think about what the LocalData and RemoteData classes are providing, and see which of the packages provides the closest match.
should i provide a service to do a "reservation" for the booking?
I dont recall any requirements for anything remotely like this. There are plenty of additional features we could add to the system (and we would have to add them in a real system). But at the end of the day, we are not building a real system, we are doing an assignment for Sun. You could mention how your application could be enhanced to do reservations in your documentation (thereby showing that you have thought about it, and that your system is flexible) but I would recommend against writing any code itself for this.
you would be going outside of scope (think in real life: would your employer prefer you to finish early and get on to a new task, or would they prefer you to build a great system that the client hasn't asked for and won't pay for)
what you think might be needed for a reservations system may not be what is eventually wanted for a reservations system, so it may end up being rewritten. (these last two are covered in the You Aren't Gonna Need It practice.
The more code you add that has nothing to do with the requirements, the more the examiner has to look at and discard as irrelevant - do you really want them doing this? Or they may find something wrong in your aproach, and mark you down. You cannot gain extra marks for doing extra work, but you could loose marks.