Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Overall Design

 
Kirk Maze
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One particular aspect of the assignment is bothering me greatly.

It's this : "The remote client code that you write must provide all the public methods of the suncertify.db.Data class."
I have had it pounded into my brain that you don't allow your client visibility to data access code like getRecord(), criteriaFind(), lock
(), etc. Instead the interface between the client and server should be an abstraction which applies to the client - in this case perhaps something like makeReservation(), findFlight(), getAvailableSeats(), etc.
If I provide all the functionality to the client that the Data class allows, but do it with an entirely different client/server interface
than the data class has, will I fail automatically? Does anyone know someone who has passed with this approach?
Even if they are going to ding me, I'd rather write code that is correct, but if they're going to fail me, then I'll knuckle under.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes you are right. the Client should only call methods like bookSeats().
What the requirement is really stateing that to get to that abstraction, you need a couple of things. 1st an Interface that has all those "Bad" methods. Then two classes that implement it. LocalDataAccess and RemoteDataAccess, then you can wrap them into a DataAccessFacade, and this facade class is the class that you will ahve your client talk to.
OK, now on to administrative stuff...
"Kirk"-
Welcome to the JavaRanch! Please adjust your displayed name to meet the
JavaRanch Naming Policy.
You can change it
here.
Thanks! and welcome to the JavaRanch!
Mark
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by mazekl:
One particular aspect of the assignment is bothering me greatly [...] I have had it pounded into my brain that you don't allow your client visibility to data access code like getRecord(), criteriaFind(), lock(), etc. Instead the interface between the client and server should be an abstraction which applies to the client [...]
In addition to the above I'd like to point out that, by that line of reasoning, Oracle, SQL Server and all their friends are somehow fundamentally "wrong" applications.
While some will no doubt be nodding their heads -- especially those who've had to deal with their idiosyncrasies (ever tried storing NaN in SQL Server? C-R-A-S-H!) -- I would tentatively disagree
You're being asked to build a database server and a fat client. Nothing wrong with the server, fat clients are out of vogue but hey, you can at least provide a clean conceptual if not physical separation between business logic and presentation.
- Peter
 
Jason Boutwell
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Peter wrote:
"You're being asked to build a database server and a fat client..."
Once I fully understood and accepted this, my life became a whole lot easier. Of course, I still didn't like it.
-- jason
 
Kirk Maze
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK guys, I'll build an ugly fat client app, but I don't have to like it!
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK guys, I'll build an ugly fat client app, but I don't have to like it!

Just think of it like Vegetables, they are there and it does the body good. Oh wait that's milk. Well it's the other meat, no that's Pork. Oh nevermind.
Mark
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic