• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Using domain objects as part of Remote interface?

 
Trond �vstetun
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all.

I have just started to implement my assignment for the SCJD exam, the B&S version..

I have a question that you could call quite generic though:
When I implement the (remote) server interface (i am thinking of using RMI with serialized objects), would it be a good idea to use domain objects instead of the ugly-bugly String[]-representation of data that the DB-interface suggests?

From an ObjectOriented point-of-view this seems to me to be a good solution, but how should I then worry about locks and such? I guess the client must do the locking (havent gotten around to selecting a locking strategy yet though..) and a Lock domain object doesnt seem to me like a good idea..
Could distinguish between a EditableContractor (containing a non-visible lock) and a Contractor (as in two interfaces or full-fledged classes w/o interfaces) and make my "server" supply several modes of selection?

Also in an MVC world, using a Model that contains meaningful objects seems like a good idea to me..



Any feedback would be greatly appreciated

Trond.
 
Kalle Tjarnlund
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Trond �vstetun:
Hi all.

I have just started to implement my assignment for the SCJD exam, the B&S version..

I have a question that you could call quite generic though:
When I implement the (remote) server interface (i am thinking of using RMI with serialized objects), would it be a good idea to use domain objects instead of the ugly-bugly String[]-representation of data that the DB-interface suggests?

From an ObjectOriented point-of-view this seems to me to be a good solution, but how should I then worry about locks and such? I guess the client must do the locking (havent gotten around to selecting a locking strategy yet though..) and a Lock domain object doesnt seem to me like a good idea..
Could distinguish between a EditableContractor (containing a non-visible lock) and a Contractor (as in two interfaces or full-fledged classes w/o interfaces) and make my "server" supply several modes of selection?

Also in an MVC world, using a Model that contains meaningful objects seems like a good idea to me..



Any feedback would be greatly appreciated

Trond.


Hi Trond!
For starters I must just state that I am not doing the same assigment as you are so maybe my solution is not applicable at all for you :-(.

Anyway, I have a solution with RMI and domain objects since I also think that this is a cleaner approach. Still I keep my locking mechanism separate from the domain objects. My locking only applies to record numbers and the domain objects are not involved in the locking. My locking is done in the RMI-objects (that is on the "server"-side).

Hope this can help you a bit at least...

Best Regards,
Kalle
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic