Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: exposing the MetaData to the client

 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone,
I have some questions how to expose the MetaData to the client:
I have following design for the Data-Layer:
the header-informations are read by DataSchema, a singleton instance.
DataSchema also creates an immutable object MetaData (thanx, Vlad) which provide informations needed by the client.
Further DataSchema contains a getMetaData method which returns MetaData.
In local mode the client can call getMetaData from DataSchema directly. For the remote mode, I have created a new Class called RemoteSchemaImpl implementing the remote interface RemoteSchema.
RemoteSchemaImpl's only method beneath its constructor is getMetaData, returning the serializable object MetaData.
1. Sounds a little bit complicated, I know, but I don't know a better way to provide the MetaData to the client for the 2-tier solutions.
Comments?
Thanks a lot in advance
Ulrich
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ulrich,
Sounds a little bit complicated

Agreed
I don't think it is a good idea to let dataSchema have a method getMetaData(), since DataSchema is MetaData.
There many ways to do it.
Example 1:
You don't have MetaData class. Your Data class has a method getDataSchema (or getMetaData()), which returns DataSchema.
EXample 2: If your DataSchema contains some information needed for the server application and you don't want to expose it to the client:
You can have two classes:
One abstract class MetaData(contains all getters needed by client) and the DataSchema class extending MetaData.
Your Data class will have than MetaData getMetaData() method, which returns actually DataSchema. It would hide any complexity from the client.

Best,
Vlad
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vlad
thank you for your reply.
One abstract class MetaData(contains all getters needed by client) and the DataSchema class extending MetaData.

That sounds cool. I will try this way and surely will have some more questions to ask
Greetings
Ulrich
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vlad and Ulrich,
I have finished the core part, and now is trying to fine tune the programs.
At first, I read my MetaData from the database file, and I have this:

And I get the following:

These string values will be displayed in the JTable's header.
However, in my instructions:

My question is:
Should I keep displaying "name" in the JTable Header, or I should display "Hotel Name" instead of "name"?
I have tried this before, I put this mapping into the "suncertify.properties" file, but when it really display in the header field, it makes the length to be very long, which is very ugry
Any comments?
Thanks.
Nick
[ December 08, 2003: Message edited by: Nicholas Cheung ]
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Nick,
Should I keep displaying "name" in the JTable Header, or I should display "Hotel Name" instead of "name"?

Well, I tried to display names from "descriptive name" list. I changed them a bit: Hotel name-> Hotel, Cutomer .... -> Customer and so on.
Best,
Vlad
P.S. I would suggest to change the name of your class MetaData to ColumnInfo or something like that. MetaData logically should a class describing all columns (e.g. the array of columns), not a single column.
 
Seid Myadiyev
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would like to ask if I may "assume" the structure of the record from the instructions document and create a "Room" class based on the assumption with appropriate data types for each instance field. For example:

Or do I need to inspect the db file at runtime hold everything in abstraction (without any specific instance field names and types) and only make a wrapper for the array of strings which represent the field values? For example:

Thank you!
Seid
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Seid,
I would preffer the second option (with array). GUI is required to be developed with option of future functionality enhancements. The second option helps client to do so by providing more generic framework.
Best,
Vlad
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vlad, hi Seid,
Seid,
I have tried also to use the descriptive names, but they're so long, now I will use the shorter field names.
Hi Vlad,
I have now thought a little bit about my further design concerning the MetaData(or whatever I will call it later, now, excuse me, I will keep this name
I.I can't implement getMetaData() in the Data-Class because I'm using the 2-tier approach (I suppose that we are not allowed to add further methods in the DBAccess interface).
Because I have DataSchema as a Singleton, I will have in this class getInstance()-method which returns the singleton (like you suggested, DataSchema extends MetaData):

Now, some thoughts concerning the exposing of MetaData for the client.
I think I have two options:
1. to add one more RemoteObject which includes a getMetaData()-method or
2.to include this method in one of my two already existing RemoteObjects, ConnectionFactory(Impl) or RemoteDBAccess(Impl). Because I can't add getMetaData to RemoteDBAccess for the reasons I mentioned above, I can add it to ConnectionFactory.
Please correct me, if you see some weak points in my reasoning
OK, let's assume that I choose the option 2:
So in ConnectionFactoryImpl I would have following method:

this is a kind of wrapper for DataSchema's getInstance() transforming the DataSchema in the User-conforming MetaData.
For the local mode, the transforming from DataSchema to MetaData will happen at the client side and look like:

I'm sorry to border you with this mass of code, but I'm a little bit lost.
What do you think about this approach?
Thanks a lot
Ulrich
[ December 08, 2003: Message edited by: Ulrich Heeger ]
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vlad,
sorry to annoy you again
I just wanted to say that I will first try my concept and will probably post my questions in a new thread.
So thank you & see you later
Ulrich
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ulrich,
I'm sorry to border you with this mass of code, but I'm a little bit lost

Stop saying sorry! I enjoy talking to you.
1. There is no way I would make another remote object just for DataSchema. I know, there were people doing that, but I, personally, don't like it. It is too complex and confusing.
2.
Solution A:
Well, I did have some kind of "hybrit" between 2/3 tier.
I did have interface DBAdapter. This adapter had no any much of the logic:
- It chained unchecked exception to checked exceptions.
- additional getMetaData() method.
I would solve the problems mentioned by you.
Solution B:
You have a standard interface (say DB) and data class implementing it.
You can create one more interface MyDB extending DB interface (which would have additional getMetaData() method). Then you can
1) just add getMetaData() method to your Data class and make it implement not DB, but MyDB. It is a bit risky (since it may be a breach of specification), but the people in this forum decided that it should be Ok.
2) create MyData class (pretty the same as DBAdapter), which would implement MyDB and call the logic from Data:

Your RemoteObject can wrap than MyDB instead of DB.
Best,
Vlad
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vlad,
thanks for your help, I will try to avoid the word "sorry" in future, sorry

1. There is no way I would make another remote object just for DataSchema. I know, there were people doing that, but I, personally, don't like it. It is too complex and confusing.

That sounds reasonable. That�s also my intuitive thought.
Your further solution looks really good.
In the meantime, I�ve now tested the approach I�ve mentioned above:
So I have now implemented following methods in ConnectionFactoryImpl:

The question is if I can argue to integrate the getMetaData()-method within my ConnectionFactory. In this article from Sun
it�s written:

In general, a factory implementation is useful when you need one object to control the creation of and/or access to other objects.By using a factory in RMI, you can reduce the number of objects that you need to register with the RMI registry.

With this statement I could justify the implementation of getMetaData-method or what do you think about that? Shall I post a new thread to ask this question?
Greetings
Ulrich
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ulrich,
I find your approach interesting. You can probably justify it: You don't have to follow patterns and so on. So, it is a valid solution.
However, I would try to avoid it, since your ConnectionObject consufes a bit from the first look. It is hard to comment it: it is a valid solution, but, I PERSONALLY, don't like it. I still beleive it is the best way to provide the client with business user interface containing all methods needed to work with the server (including getMetaData()).
I would like to ask others to join this thread to hear other opinions, since I my approach is, may be, too restrictive.
Best,
Vlad
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vlad,
thank you for your comments.
I have to think a little bit about my concept.
Greetings
Ulrich
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic