Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Client Interface  RSS feed

 
Frank Verbruggen
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have decided on an Adapter pattern for my RMI to clients for reasons discussed elsewhere.
Now I wonder, what shall I offer in my client interface...

method needed in thin client offered in DBAccess

CreateRecord not needed y
DeleteRecord not needed y
UpdateRecord -> BookRecord y
ReadRecord needed y
SearchRecord needed y
CountRecord needed n

CountRecord is a method for retrieving the size of my AbstractDataModel.
Of course, I can let my client retrieve all the records once, and then record their count, but this is very awkward.

So, then this remains, what to offer in the interface ???
 
Frans Janssen
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Frank,

I think there can be several schools of thought:

  • Provide only what is absolutely required. This will get you the leanest code and you will not risk introducing errors in parts of the code that you don't even plan to use.
  • Provide as much as possible. Then you can claim maintainability, because extension of client functionality can in many cases be done without needing to change your server.


  • I choose the second way. Not even so much for the maintainability reason, but mostly because this allowed me to use a test client that can access all server functionality, especially the functionality that I could not test using the GUI client, such as the delete and create methods.

    Frans.
     
    It is sorta covered in the JavaRanch Style Guide.
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!