This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX: B & S - Is this design too complex?? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX: B & S - Is this design too complex??" Watch "NX: B & S - Is this design too complex??" New topic
Author

NX: B & S - Is this design too complex??

S Perreault
Ranch Hand

Joined: Oct 29, 2003
Posts: 37
Hello all,

My assignment is the Bodgitt and Scarper Contractor Application.

After putting the developer's exam aside for about 6 months for RL work, I have recently picked it up. Originally I created the socket server part and didn't like it so moved to using RMI.

My main question is my design.

For starters I do not pass String arrays on the client side. Everything is contained in a Contractor object. My idea was to allow extensibility using abstract classes and interfaces so that a different database 'table' could be used and only a few classes would need to be added in order to use this new table.

I have the DBAccess interface and the Data class implementating the DBAccess class. Contained within the Data class is an abstract class I call DatabaseSchema that is extended into a class called ContractorSchema.

UI:
I have the typical UIs set up. One for the Server and one for the Client.

Client:
In order to have the front end talk to the back end, I have an interface called IContractorPortal that is implemented by ContractorDataPortal and ContractorRMIPortal. These are the 'gateway' for the front end to talk to the back end.

Server:
On the server side I have a static class called ContractorFacade that interacts with the Data class to send/retrieve information from the database. Most of the 'business' logic is contained within this class as well as the transformation from String[] <-> Contractor objects.

If the application is running in local mode, the ContractorDataPortal calls the ContractorFacade directly.

If the application is using RMI, the ContractorRMIPortal class retrieves a handle on the IContractorRemote interface (implemented by ContractorRemote_Impl) and proceeds to call ContractorFacade from ContractorRemote_Impl.

Searching
I also have an Abstract SearchCriteria class that is extended by ContractorSearchCriteria that is used to send search criteria to the back end.


My questions are:
1) Should I remove all of the Abstract classes and simply create ContractorSchema, ContractorSearchCriteria, etc.

2) In writing this post, I have noticed a flaw in my idea of being able to use a new database table. Data uses a static Synchronized HashMap for locking. Even if I extend DatabaseSchema with a new class, the Data class will still be using the identical Synchronized HashMap, right?

3) Is this all too complex or am I on the right track headed into the station.

4) Should records that have been booked appear in subsequent searches?

Thanks for reading a long post and any thoughts/ideas that anyone may have.
Perogi.


p.s. As for locking and unlocking, it is all handled serverside. The client knows nothing about how the items are locked and unlocked. EDIT This has been changed. Most locking takes place on the ContractorFacade level. END EDIT

[ May 19, 2004: Message edited by: S Perreault ]
[ May 25, 2004: Message edited by: S Perreault ]
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Perogi,

1) Should I remove all of the Abstract classes and simply create ContractorSchema, ContractorSearchCriteria, etc.


First you must be sure that all code you put in the abstract classes is *actually* reusable for any other table you'd want to support and would help to implement some future extension. BTW, that's important mainly because *you* justify them by the extensibility you've in mind (while the instructions don't care about it). In other words, if you are unsure about them, or if their code volume is low, it's possibly better to remove them: your design will be simpler, easier to explain and understand, and - last but not least - you'll have less to document...

2) In writing this post, I have noticed a flaw in my idea of being able to use a new database table. Data uses a static Synchronized HashMap for locking. Even if I extend DatabaseSchema with a new class, the Data class will still be using the identical Synchronized HashMap, right?


Right! Now if you *really* want to support multiple tables and keep a centralized locks container, you can easily change your Long recNos in some object representing a file/recNo pair.

3) Is this all too complex or am I on the right track headed into the station.


I feel it a bit complex, but it's just my opinion. I'll personnally keep the String[] records. OOH they may be less handy to work with, but OTOH they are extensible by definition, and their use doesn't require any justification in choices.txt.

4) Should records that have been booked appear in subsequent searches?


You already know what I think about it, as I replied to the same question of yours here. Now I know that, in that area, most people don't believe in my arguments. So...

p.s. As for locking and unlocking, it is all handled serverside. The client knows nothing about how the items are locked and unlocked.


Mmh... good boy!

Best regards,

Phil.
S Perreault
Ranch Hand

Joined: Oct 29, 2003
Posts: 37
Phil,

I truly appreciate the time you took to read a very lengthy post.

I will take your ideas and work with them. I will have to agree that my ambitions of having an easily extensible backend are not fulfilled. I may just keep it at a minimum and only worry about the Contractor Database.

I will probably keep the Contractor object. I really dislike using String[] to handle what (I believe) should be a fully encapsulated object. =)

Thank you very much. It is greatly appreciated.

Have a wonderful day,
Perogi.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: NX: B & S - Is this design too complex??
 
Similar Threads
Comments of the given interface
[B&S]: Using a Singleton class to represent the file resource
Could somebody suggest me about locking in standalone mode,please?
NX: Bodgitt and Scarper and design/synchronization questions
Another MUST requirement interpretation question