Create Wrapper class for DB access?

[Mark O' Sullivan]

Hi,
I have a query regarding the scjd assignment.
(1) I'm thinking of using the object wrapper pattern for the supplied DB interface when its implemented. Therefore within the object wrapper class, I have common functions to client-side, e.g. createBooking(), doSearch(). I thinking of exposing this wrapper class across the network for client-side usage. Just wondering since assignment must work in non-networked mode, must client if working in this mode access the DB interface or is it okay to let client access the object wrapper class instead, the one I create? Or would I automatically be failed for this?
Thanks.

[Roberto Perillo]

Howdy, Mark!

The methods you mentioned in your example look more like business methods, so I guess it would be better to put them in a business/services interface. You can create an interface that extends java.rmi.Remote and have its implementation use the Data class, and this would be your server. This interface can have the same methods as the interface provided to you in the assignment. You can then create a business interface, which uses the Data class directly (when running the application locally) or uses the remote server (when running the application in client mode). This interface can have the methods you mentioned in your example. This way, the GUI uses only the business/services interface, which allows changing the way the application runs without any impact. The important thing is, when running the application locally, you cannot use the server code, or you will be automatically failed.

For some examples of how it can be done, please take a look at this interesting discussion.

[Fernando Franzini]

Hi Mark

I dont think so. Cause assignment say that you must implement some interface and dont say anything how you must expose service to client layer. Read your assignment better. As our friend Roberto told you...you should think better how you will do that....I'mean wich way you'll expose your methods...and dont forget that you must writte "why" you chose it in your choices.txt.
I'm almost finish my assignment and I'm using 3 layers approach (View->Bussines->Perisistence).
Regards.

[Anne Crace]

Roberto,

I read that 'interesting discussion', and just want to clarify what I think I have. I'm getting ready to submit any time now. My Controller is in the GUI package and has a boolean parameter for local or not. It populates the table and the combo boxes I use for Search and basically does 'find' and 'reserve'. I do not expose lock/unlock to the client. I think I have a 3 tier thick client. One of those replies implied that not exposing lock/unlock to the client is thin client. I still think I am thick and 3 tier, but am a little

[Fernando Franzini]

Hi Anne

I've read this discution too a while ago. How did you do Anne ? How didn't you expose lock/unclock if you dont implemented bussines layer ?

[Roberto Perillo]

Howdy, Anne!

I'm getting ready to submit any time now.

Alright!!! I'm glad to hear that!

My Controller is in the GUI package and has a boolean parameter for local or not. It populates the table and the combo boxes I use for Search and basically does 'find' and 'reserve'.

Hum... something like the "Passive View" pattern?
Anyway, you could improve even more your project by just having a reference to the services interface in your controller and not having the boolean variable. This way, you could provide more abstraction (it would never know where data came from). You could have a factory providing the implementation of your services interface to your controller, and it doesn't have to be anything too sophisticated; a static factory could do the job.

I do not expose lock/unlock to the client. I think I have a 3 tier thick client. One of those replies implied that not exposing lock/unlock to the client is thin client. I still think I am thick and 3 tier, but am a little

3 tier means that you have 3 physical components. A layer is a logical division; a group of classes with a very specific function. The business layer is the one that deals with business rules. So, if you deal with it locally (that is, business rules being implemented on the client side), then you have a thick client, because it has business rules in it. If you have a business interface that only exposes to the client business methods (such as bookRoom() or search()), and all the client does is use it "dumbly", then you have a thin client.

[Mark O' Sullivan]

Hi,
Thanks for your response, very helpful! Read that article as well, very enlightening. Ya, this business approach looks great, I'm just thinking of where I actually could do the locking with this approach as within my assignment, I have a unique cookie returned to client for some methods, e.g. lock. Would this be done then in the business logic section? Also with this I'm trying to consider how I ensure a different cookie value presisted for each client and the only way I can think of use, some sort of synchronization, e.g. synchronized keyword and synchronize on critical code or functions.
E.g.
Business logic

public synchronized void bookRoom{
long cookie = record.lock();
update(cookie);
uplock(cookie); 

Is it correct to let the synchronization done within this layer?
Sorry, this probably is another question can start new thread if needed.
Thanks.

[Anne Crace]

Fernando,

My thinking is the Controller IS business layer, even though it sits in the gui package. It is the 'middle man' between the GUI (view) and Data(model). I do my locking/unlocking from Data and the LockManager class I have to perform logical locking. Data.lock > LockManager.lock.

[Roberto Perillo]

Howdy, y'all.

Well, this discussion is getting interesting!

Anne Crace wrote:My thinking is the Controller IS business layer

Well... the controller is the guy that knows the GUI and the model, it isn't exactly business layer. If we think purely, model is an abstraction of a particular domain, so I'd say the controller is out of the business layer. For a Swing application, the controller role can be done by an ActionListener; in a web application, it can be represented by a HttpServlet.

Mark O' Sullivan wrote:Ya, this business approach looks great, I'm just thinking of where I actually could do the locking with this approach as within my assignment, I have a unique cookie returned to client for some methods, e.g. lock. Would this be done then in the business logic section?

Yup. That's right. This lock/update/unlock stuff looks like business rules, so the business layer is the place to put this code.

[Fernando Franzini]

Hi Anne

As Roberto already explain very enlightening...bussines layer is a place where you put your bussines rules and it should be separate from the client layer. I mean, this implementation can't be inside client layer.
I've understood that you implemented it inside client layer like a "controler class" between data layer and view classes.....so....you are using something like passive view pattern or just an ActionController. I dont see any problem with that...you just need justify in your design decision in choices.txt.

[Anne Crace]

Roberto,

Thanks for your reply! I think I will try to add that factory, as it shouldn't be too hard. I'm at the point that many others have reached and just want to get rid of the $%$@ thing! Reading your explanation, I have a 2 tier (physically) and thick client even though the GUI dumbly relies on the Controller, the Controller is packaged with the GUI classes, some business logic is performed here. Not all but enough to qualify it as thick. I pretty heavily used Andrew's book as a road map, but I could never find a concrete answer in that book if he uses 2, 3 or thick or thin. Please don't ask me to read that thread "Should lock methods be callable from the client". I have it bookmarked and have read it many times! lol!

Mark,

I use synchronization in my LockManager on the HashMap that holds my record number/ lockCookie pairs as well as when performing read/write/delete (all methods of my file access class are synchronized) from my file access class.

[Roberto Perillo]

Howdy, Anne!

I'm at the point that many others have reached and just want to get rid of the $%$@ thing!

I know exactly how you feel. Just make sure you don't miss any "must", and it should be fine!

Please don't ask me to read that thread "Should lock methods be callable from the client". I have it bookmarked and have read it many times! lol!

Oh



Good luck!!!

[Anne Crace]

Just make sure you don't miss any "must", and it should be fine!

I think I'm good here I have a hard copy of the specs with all the 'musts' highlighted and checked them off if they were OK.

[Anne Crace]

I think I straightened out what my architecture is. It is 2 tier thick client. The package structure makes it 2 tier and I do have a fair amount of business logic being performed by that Controller so it's a thick client. I found this article on the Evil Empire's MSDN website Three-tier Application Model. Between this and Roberto's explanation above, I think I have it right I think it could be thought of as logically 3 tiered, but that's about as far as any 3 tier stuff goes in my setup.