Design Review

[Vlad Rabkin]

Hi,
Here is my application design:
Client:

ClientConnectionFactory:
+-- DBAdapter getLocal()  --- DBAdapter
|
+-- DBAdapter getRemote() --- DBAdapterRemote

Remote Server:

                  
DBFactory: 
                         +- DBAdapterRemote 1 -+ 
DBAdapterRemote create() +- DBAdapterRemote 2 -+- DBAdapter - Data
                         +- DBAdapterRemote 3 -+

public interface DBAdapter {
    public void update(RecordModel record, long cookie)
       throws RecordNotFoundException,
              SecurityException,
              IOException;
    public RecordModel[] find(RecordModel criteria) throws IOException ;
    public RecordModel read(int recNo)
      throws RecordNotFoundException, IOException;
    public int create(RecordModel record)
       throws IOException;
    public void delete(int recNo, long cookie)
              throwsRecordNotFoundException,
SecurityException,
IOException ;
    public long lock(int recNo) throws RecordNotFoundException, IOException;

    public void unlock(int recNo, long cookie)
       throws RecordNotFoundException, SecurityException, IOException;

    public MetaDataModel getMetaData() throws IOException;
}    

Client:
There is no any Adapter class on the GUI client:
All methods in DBAdapterLocal throw IOException. The difference beetween DBAdapterRemote and DBAdapter
is that DBAdapterRemote has all methods throwing RemoteException.
Since RemoteException is a subclass of IOException, there is no need for an additional adapter on the GUI client:
DBAdapter can be casted directly from DBAdapterRemote. (see Max book). The RemoteException will be not differed
from IOExption (they will be handled equally).
Server:
First DBFactoryImpl (implementing DBFactory) will be ininitialized (mutition - single object).
DBFactory provides only one methods: create() which creates an every time a NEW remote object DBAdapterRemote.
The ONLY purpose of the class is expendability of the server. Factory can hide in future pretty much logic of
for remote object creation and management (e.g. remote object POOLING).
DBAdapter is a mutition (single instance), wrapping/adapting DB interface.
Advantage of mutition DBAdapter/Data:
- it's more efficient for the server, because it doesn't have to provide multiple instances (it needs less memory).
- is a BIT simpler for server implementation

Disadvantage of mutition DBAdapter/Data:
- it's less efficient for the clients, because they have to share instances of DBAdapter and Data.


The only point where I am not sure my statement that having Adapter/Date as mutition is performant
for the server, since I personally beleive (but am not sure), that having multiple instances : one per
thread, should be faster than having multiple threads for one instance (for the server).
The only issue where I am sure is that it saves memory.
I am now ready for critic and comments

Tx,
Vlad
[ September 22, 2003: Message edited by: Vlad Rabkin ]

[Ulrich Heeger]

Hi Vlad,
What are you return object RecordModel and MetaDataModel?
Does it mean you don't have a Controller-Class at the client-level?
You wrote:

Server:
First DBFactoryImpl (implementing DBFactory) will be ininitialized (mutition - single object).
DBFactory provides only one methods: create() which creates an every time a NEW remote object DBAdapterRemote.
...
DBAdapter is a mutition (single instance), wrapping/adapting DB interface.
Advantage of mutition DBAdapter/Data:
- it's more efficient for the server, because it doesn't have to provide multiple instances (it needs less memory).
- is a BIT simpler for server implementation

Does it mean you have for each client a new remote object but all clients share one Data-Class?
Regards
Ulrich

[Andrew Monkhouse]

Hi Vlad,
I think you are right that you will save some small amounts of memory by only having the one instance of DBAdapter. But I think it is small amounts only. I think your main advantage is going to be in simplicity, especially for junior coders to understand.
Performance is a bit harder to quantify. If all your DBAdapter methods are doing is wrapping the calls to the Data methods, then on a single CPU system it is quite possible that having only a single instance of the DBAdapter is going to be more performant than having multiple instances. Whereas if you are doing work in the DBAdapter methods and/or you are on a multi CPU system then having multiple threads might be a little more performant.
I think for potential scalability, having multiple instances of the class that is doing the work (verifying records may be updated, comparing record values with search criteria, etc.) may be better. Have a separate class that only has a single instance for just getting the records in and out of the datafile or cache.
Of course, most people here will be looking for simplicity in their design, so these comments do not apply for them
Other random thoughts...
Is DBFactory really a database factory? I think it is connection factory. I think the junior programmer might be confused by the name.
I think you have multiple different ways of writing your list of exceptions in the interface. I can understand and agree with at least two different ways (one for wrapping, one for non wrapping), but you have 4 different styles - I think this is too many.
Regards, Andrew

[Vlad Rabkin]

Hi Ulrich,

What are you return object RecordModel and MetaDataModel?

I do it to provide a generic framework. RecordModel contains field values and information (name, length). Doing so, the client is very flexibile to changes in database structure. MetaData is the whole database schema (information about each field in database).

Does it mean you don't have a Controller-Class at the client-level

Of course I do. I didn't show it, since it was not the point I am discussing here, but you are right a GUIContoller is used to connect GUI View and Database:
GUIView->GUIController->DBAdapter

Does it mean you have for each client a new remote object but all clients share one Data-Class?

Exactly! Actually I can switch it easily to have only one Remote Object (since I have DBFactory), but I don't see any meanfull advantage of having one remote object for all clients.
Best,
Vlad

[Vlad Rabkin]

Hi Andrew,
Tx for feedback!

I think for potential scalability, having multiple instances of the class that is doing the work (verifying records may be updated, comparing record values with search criteria, etc.)

Does it mean that you suggest to have DBAdapter object per client (as Remote Objects do)?
DBConnectionFactory:

                         +- DBAdapterRemote 1 -- DBAdapter -+
DBAdapterRemote create() +- DBAdapterRemote 2 -- DBAdapter -+- Data
                         +- DBAdapterRemote 3 -- DBAdapter -+

or did did you mean Data class?

Is DBFactory really a database factory? I think it is connection factory. I think the junior programmer might be confused by the name.

Agreed. I must say that I haven't "polished" the names and style for classes and it context yet.

but you have 4 different styles - I think this is too many.

Do you mean the eay they are formatted? If so, I agree, I will change it. If not, I am not sure I understand you.
Tx,
Vlad

[Andrew Monkhouse]

Hi Vlad,

Andrew ...having multiple instances of the class that is doing the work...
Vlad Does it mean that you suggest to have DBAdapter object per client [...] or did did you mean Data class?

My comment was a bit vague, because it was a bit theoretical. I was trying to get at what things may make your code a bit more performant at a theoretical level. In reality, I would not go down this path unless performance was an issue.
But, to clarify. It depends on whether the bulk of the work is being done in DBAdapter or in Data. For example, when you do a call to find(), I presume that the Data.find() method is doing all the hard work of retrieving each record, validating whether it is a match for the criteria, adding it to a collection, then finally returning an array of matching records. By comparison, the DBAdapter is doing comparitively little work - just wrapping that array of records into an array of RecordModels. In this case, since most of the work is done in the Data class, you would get best performance by having multiple instances of the Data class. However as I also said: this is pretty much dependant on you having multiple CPUs and a JVM that uses the multiple CPUs.

Vlad Do you mean the eay they are formatted? If so, I agree, I will change it.

Yes that is exactly what I meant.
Regards, Andrew
[ September 23, 2003: Message edited by: Andrew Monkhouse ]

[Ulrich Heeger]

Hi Vlad,
thanks for your reply.

I do it to provide a generic framework. RecordModel contains field values and information (name, length). Doing so, the client is very flexibile to changes in database structure. MetaData is the whole database schema (information about each field in database).

I'm still busy with my Data-Access-Layer but I'm unsatisfied of thinking to return a String-Array back to the client. So I prefer your way
Just a question: Why have you the getMetaData()-method implemented in DBAdapter? What for the client should use informations concerning MetaData?
In your RecordModel you have allready defined the name of the fields
Greetings
Ulrich

[Vlad Rabkin]

Hi Ulrich,

Why have you the getMetaData()-method implemented in DBAdapter? What for the client should use informations concerning MetaData?
In your RecordModel you have allready defined the name of the fields

First, to understand it better I would suggest you to take a look at this thread:
MetaData Framework
RecordModel contains:
values (String[])
its fields information (MetaData)
So MetaData is wrapped in RecordModel.
You don't need MetaData while working with readRecord method. Here you are right.
BUT, how would the execute create method (our GUI Client doesn't implement create method, but server interface must allow him to do it)?
You GUIClient would have to create an instance of RecordModel.
How can you create instance of RecordModel without knowing MetaData?
Of course, you could do following:
Read any record to get RecordModel containing any record, then get its MetaData and use it to create new recordModel instance to be used for create. What are you going to do if the database is empty? It wouldn't work.
Having getMetaData you can do following:
1) MetaData metadata = db.getMetaData();
2) RecordModel newRecord = new Record(metadata);
3) newRecord.setValue("hotel", hotelStr); newRecord.setValue("city", cityStr); and so on...
The only thing which I think now about is find method. I will probably change it from:
RecordModel[] find (RecordModel criteria);
to:
RecordModel[] find (String criteria);
Where string would have following format: <Fieldname1>=<value1>, <Fieldname1>=<value1>, ...
It would allow in future to use:
other operations in addition to "equals" (e.g. <>, like and so on)
to use wild cards (*,%)
Remember, the idea to use RecordModel is not new. The problem is how to implement it so that, it doesn't become to complicated. I am struggling myself now with this issue.
Best,
Vlad.

[Vlad Rabkin]

Hi Andrew,
What time was in Australia at which you have sent the reply?
I guess around 7pm, but I can see some mails in other topics which you have sent early morning at your time. You are really an insomnia guy.
Jim is a sheriff. I think we will have to ask him to restrict you access to the forum to max 8 hours a day

My comment was a bit vague, because it was a bit theoretical.
I presume that the Data.find() method is doing all the hard work of retrieving each record, validating whether it is a match for the criteria, adding it to a collection, then finally returning an array of matching records. By comparison, the DBAdapter is doing comparitively little work - just wrapping that array of records into an array of RecordModels.

Ok. I agree: it really depenes on different things, expoecially on JVM<->CPU configuration.
In my case DataAdapter.find() makes also very much work (almost the same as Data.find() does ). Data.find() return only ids of found records by prefix search. DataAdapter.find() has to call read again for each found ids (to get a Record) and filter results, according to equals() criteria (instead of startsWith()). Data.find() is synchrononized, DataAdapter.find() is not synchronized() (since it invokes only Data.find() and loop of Data.read(), which are synchronized inside Data). And in this case I would say you 100% right: I should allow multiple instances of DataAdapter. I know, your idea was "theoretical", but it is alway good to apply theory in "practice".
Tx for idea!
Vlad

[Ulrich Heeger]

Hi Vlad,
thanks for your reply.
now I understand
Regards
Ulrich

[Jim Yingst]

Jim is a sheriff. I think we will have to ask him to restrict you access to the forum to max 8 hours a day
Why's that? Max isn't here anywhere near 8 hours a day.

[Andrew Monkhouse]

Jim is a sheriff. I think we will have to ask him to restrict you access to the forum to max 8 hours a day

But I already said that with warm weather approaching I will cut down my hours! Promise!
It is already warm enough to go swiming, and I spent a few hours snorkelling today. And I should be able to continue snorkelling until April next year Gotta love these 8 month long warm spells

[Vlad Rabkin]

Hi Andrew,

And I should be able to continue snorkelling until April next year Gotta love these 8 month long warm spells

Cool
But now I have to start to cry: That is exactly what I can't do till April
Best,
Vlad
[ September 24, 2003: Message edited by: Vlad Rabkin ]