This week's book giveaway is in the JavaScript forum.
We're giving away four copies of Getting MEAN with Mongo, Express, Angular, and Node and have Simon Holmes on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Design choices Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Design choices" Watch "Design choices" New topic

Design choices

Jae Zee

Joined: Feb 09, 2005
Posts: 15
I have some serios contemplations about my client and server design.

On the Client side:
Im using MVC with observer that includes a controller, View and DataModel/TableModel. I am thinking of also using the facade pattern to keep my server invisible from the client. I think that functions like findContractor() and bookcontractor() should go in the DataAccessFacade(on the client side). I just keep finding myself mixing upp functionalities that are to be in the DataModel class(MVC) and those that are meant for the dataAccessFacade(Facade).

On the Server side:
I have just my plain old and DBacess but im thinking of using adapter classes here and maybe a ConnectionFactory. Still again I'm unsure where the line goes btw the dataAccessFacade on the CLient side and classes on the server side( say its called localDataAccess or DataAdapter).

I've read a lot of topics written by Mark Spritzler, Bharat Ruparel,
Max Habibi and co and I will be sooo grateful for some useful advice


Jae Zee

Joined: Feb 09, 2005
Posts: 15
Please could someone post a reply. I'd really appreciate it
Ken Krebs
Ranch Hand

Joined: Nov 27, 2002
Posts: 451

You seem to be on the right track. Just keep in mind that the only purpose of your TableModel is to act as a helper for your JTable so it can render your data model. Therefore, the TableModel should not have any business/persistence logic. On the server side, it depends on whether you have a 2 or 3 layer design. With a 2 layer design, your business and persistence tiers are combined into a single layer which muddies things up a little. With a 3 tier design, the business methods such as findContractor() and bookContractor() are in the business layer while methods that read/write to disk are in the persistence layer. A 2 layer design is OK if your business logic is simple but it still helps to think in 3 layers conceptually to help keep clear in your mind the roles, responsibilities, and collaborations that are at play in your application.

Hope that helps.

kktec<br />SCJP, SCWCD, SCJD<br />"What we observe is not nature itself, but nature exposed to our method of questioning." - Werner Heisenberg
Jae Zee

Joined: Feb 09, 2005
Posts: 15
thanks for the reply

I have the Bodgitt and Scarper assignment and I have an interface that I must use. Am I still on the right track using facade? Since this means creating two classes for remote and standalone. Inevitably I find it wierd that my data class MUST be called means that I need the same class for remote and standAlone. Maybe an adapter pattern is better anyway?

I'd be real grateful for an answer on this one
Don't get me started about those stupid light bulbs.
subject: Design choices