Win a copy of Succeeding with AI this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
  • Junilu Lacar
  • Tim Cooke
  • Jeanne Boyarsky
  • Knute Snortum
Saloon Keepers:
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
  • Piet Souris
  • salvin francis
  • fred rosenberger
  • Frits Walraven

Architectural Complexity

Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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."
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
We're all out of roofs. But we still have tiny ads:
Two software engineers solve most of the world's problems in one K&R sized book
    Bookmark Topic Watch Topic
  • New Topic