Using Both Rich & Thin Client

[Daniel Simpson]

I was wondering if I would get points off for this approach if I used a thin client in local mode and a rich client in networked mode? Would I fail because of that? My doc says:

Architecturally, this mode must use the database and GUI from the networked form, but must not use the network server code at all.

I don't believe this would violate it. I have a connection class that would either return a DBLocalAdapter (local thin client) or a DBRemoteAdapter (network rich client) depending on the connection. The reason I ask this, is that it seems redundant to have a Data class that implements the DB interface and have to create an adapter that does the exact same thing as the Data class. It would be much easier to just use a Data object and expose the business methods book and search to the client in local mode.

The reason I ask about using a rich client in networked mode seems quite dumb, but I'm confused on how I would use a thin client in networked. Serialize the Data class and pass a Data instance back and forth? Max uses a rich client in his book, and it seems like the best way to go for networking at least.

Does this approach sound reasonable or simply ridiculous?

I need help. Thank you so much!

[Nicholas Cheung]

You can do so definitely, but just keep in mind, in case there are 2 coding styles for local and network mode, the client code could not be reused, and this might affect the O-O marks.

In fact, I dont think we need to have 2 different client codes for the 2 modes, even in Max's book, he has used the same set of client codes (thick client) for both modes.

For the networked mode, as discussed in other threads, if you use thick clients, you must make sure that your transactions are serializable, and the data should be consisent between transactions. Even you think you have tested without any problems (In fact, I think most of us have carried out such tests), finally, we might still score 44 out of 80 in the Locking part. That means, there are still something that we missed out, but we dont know what's that issue.

Nick

[Daniel Simpson]

Hey Nick, thanks for the reply! If I were to remain consistent with using thin clients for both local and networked. How would I do a thin client in networked mode? I'm saving networking for last. hehehe I have all my database stuff done and my local mode is almost complete (finishing up on GUI and minor stuff) and then it's off to networking. So if you have any suggestions about how I would implement a thin client in networked mode, it is much appreciated. Thanks!

[Nicholas Cheung]

You might consider to keep the locking mechanism no matter it is a network mode or non-network mode, and this mechanism is kept at the server. Thus, the client in fact does not need to worry about whether it is a local client or remote client. Of course, the user needs to know which server (local or remote) to be connected, however, the client codes could be written so that the *connectivity* of the server could be transparent.

Nick

[Jim Janssens]

I had a similar problem. let me explain my approach:

I have a thin client. All my logic (incl locking etc) is located at the server side. So all that my client does is calling remote methods and supplying it data to work on. All the locking stuff is handled behind the scenes at rmi server side. So if I would book a contractor I would do:

remoteService=getRemoteService();
remoteService.book(contractorData);

In stand alone mode, the 'getRemoteService()' returns a new instance of the RemoteServiceAdapter which is normally accessed over rmi...