File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Architectural Complexity 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 "Architectural Complexity" Watch "Architectural Complexity" New topic

Architectural Complexity

Graham W Lowe

Joined: May 07, 2002
Posts: 6
After finishing the database and client networking portion of the assignment, I am beginning to have concerns about the overall complexity of the architecture I've designed. I worried that I might be docked marks for going to far.
Basically along with the low level database I have created a Data Abstraction Layer composed of a FlightDAO (Data Access Object) which handles all persistence related operations. I'm using RMI as the underlying network protocol and the DAO is simply passed a reference to either a DataProxy or Data object depending upon whether local or remote database access is required.
On top of this layer, I have a Business Layer, which handles all the business logic related to searching and booking flight. In this layer I have 2 classes a ReservationSystemController which delegates it's actions to a TravelAgentDelegate class which encapsulates any business logic for searching and booking a flight (e.g., don't book more seats than are available for a flight). It accomplishes this through interacting with FlightDAO passing it Flight value objects for either searching or for booking. When searching, the FlightDAO dynamically constructs queries in the String format acceptable by the Data.criteriaFind method using reflection on the Flight value object to call the appropriate accessor methods.

My justification for this extensive layering approach is that Fly By Night is a growing travel agency whose persistence needs may soon outgrow their home grown database. In fact, they may even in future move to a web based UI. By decoupling the 3 layers--the persistence access, the business logic and finally the presentation--they should be able to swap to a vendor database or xml persistence engine or Servlet/JSP presentation layer without affecting too much code.
Has anyone who passed gone to this level of abstraction? I'm worried about the statement, "A clear design, such as will be readily understood by junior programmers, will be preferred to a complex one, even if the complex one is a little more efficient than the simple one."
Sai Prasad
Ranch Hand

Joined: Feb 25, 2002
Posts: 560
I asked this forum about using business objects and DAO instead of DataInfo. Someone advised me to implement simple design and not to use any business objects like you use in J2EE env. I suggest you use the existing FieldInfo, DataInfo and Data objects along with RMI Server Factory and RMI Server objects.
Keep it simple. Even though your design incorporates future changes, I think it is somewhat beyond the reach of a junior programmer.
I agree. Here's the link:
subject: Architectural Complexity
It's not a secret anymore!