A suggestion with persistence mechanism
Hello there!
I am facing for the 1st time in my life the problems of projecting and developing an application using "serious" OO analysis and design within the Rational Unified Process..
What I have to do for the final exam of my course is a web application which has to respect the MVC pattern (or anyway the logical separation between entity-control-boundary classes) with JSP...
Following this article http://www.ibm.com/developerworks/rational/library/content/RationalEdge/aug04/5670.html
and above all the picture #11 (http://www.ibm.com/developerworks/rational/library/content/RationalEdge/aug04/5670_fig11l.gif )i arrived to draw this sequence diagram for the retrieve task of persistency architectural mechanism:http://img117.imageshack.us/my.php?image=persistenceretrievepc3.gif
Here the Client is meant to usually be a Control class which talks to the ObjectFactory in order to get an istance of a PersistentObject (eg: User) stored in the DB with a precise 'key' (eg: primaryKey).
Today I wanted to transform this seq. diagr. in Java code and couldn't solve the following problem: how to manage the fact that the make() method of ObjectFactory has to receive the name of a persistentclass (eg User or Item or whateverelse) and then starting the sequence of operations that will bring to an object of that type instanced with the values retrieved in the DB? I thought I should use something like this:
public Object make (String persistentClassName, String searchKey)throws ClassNotFoundException, InstantiationException, IllegalAccessException{
Object PersistentClass = Class.forName(persistentClassName).newInstance();
String DBClassName="DB"+persistentClassName;
Object DBClass = Class.forName(DBClassName).newInstance();
//.... return PersistentClass;
}
but how could I call a method on an Object object (something like DBClass.retrieve() is not possible!)?
Do you have other ideas on how to implement this mechanism and above all the ObjectFactory class?
Do you know some Case Study available somewhere on internet?
I hope that a "Saint" will help me!! :)
thanks a lot since now!
BYE
[2393 byte] By [
smokinga] at [2007-11-27 5:50:30]

# 1
> Hello there!
> I am facing for the 1st time in my life the problems
> of projecting and developing an application using
> "serious" OO analysis and design within the Rational
> Unified Process..
RUP? Good luck.
> What I have to do for the final exam of my course is
> a web application which has to respect the MVC
> pattern (or anyway the logical separation between
> entity-control-boundary classes) with JSP...
>
> ...
>
> but how could I call a method on an Object object
> (something like DBClass.retrieve() is not
> possible!)?
If all these Objects will implement a common interface or extend from a common base class, you just need to cast DBClass (bad name, that's an Object of the class in question, not a Class object) to that interface or class and call the method. If the Object is not an instance of that interface or class it will fail.
I would strongly suggest this approach. There is another way to do it but it's a lot more code and isn't as clean, IMO.
# 2
Dubwai, thanks for your reply!
Can you please give an example of what you would implement as an interface and how to extend it.. You mean PersistentClass an interface which will be extended eg. by Customer, Shop etc..?
Another thing i cannot exactly understand is how to get rid of the fact that the Controller calls the method make of the ObjectFactory passing it customerID. I would like to add flexibility to the schema in order that the controller doesn't need to know the SQL query but that at the same time it can ask for something different from "Customer whose id =customerID"...
I thought to add a class SQLDAO and include there methods like getAllCustomersWithName (name) and let the Controller do things like:
make (Customer, SQLDAO.getAllCustomersWithName (name))
so the DBCustomer doesn't have to create the sql but just to execute it.
Is this OO? Otherwise, how could i do?
Thanks again really a lot!
# 3
> Dubwai, thanks for your reply!
> Can you please give an example of what you would
> implement as an interface and how to extend it.. You
> mean PersistentClass an interface which will be
> extended eg. by Customer, Shop etc..?
Perhaps. Your make might look like this:
public PersistentObject make (String persistentClassName, String searchKey)
throws ClassNotFoundException, InstantiationException,
IllegalAccessException
{
Object PersistentClass = Class.forName(persistentClassName).newInstance();
String DBClassName= "DB"+persistentClassName;
return (PersistentObject) Class.forName(DBClassName).newInstance();
}
> Another thing i cannot exactly understand is how to
> get rid of the fact that the Controller calls the
> method make of the ObjectFactory passing it
> customerID. I would like to add flexibility to the
> schema in order that the controller doesn't need to
> know the SQL query but that at the same time it can
> ask for something different from "Customer whose id
> =customerID"...
There are a lot of ways to approach this. You might want to read up on
the AbstractFactoryPattern. But this is something that's hard to pull off
in a really clean way.
> I thought to add a class SQLDAO and include there
> methods like getAllCustomersWithName (name) and let
> the Controller do things like:
> make (Customer, SQLDAO.getAllCustomersWithName
> (name))
> so the DBCustomer doesn't have to create the sql but
> just to execute it.
> Is this OO? Otherwise, how could i do?
Is it OO? Well if I answer that in either way it might spark off a flame
war. It's not my favorite approach. Perhaps for the scope of this work
(it's a school project, right?) this will be perfectly fine. It's kind of rigid
and requires adding another method each time you need another way
to look up things. For now, don't bite off more that nyou can chew. If
you end up with time later come back with what you have and
somebody will surely give suggestions.
# 4
hello again!
I thought again and again about this mechanism and honestly i agree 100% with you when you suggest not to bite off more that i can chew: I'm getting really stressed by this university project!:)
Today i watched also what is written about the DAO pattern here: http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
What i finally decided to do looks similar to this:
http://img505.imageshack.us/my.php?image=modellodesignlf1.gif
Of course this is a simplified diagram just to let you understand that the ObjectFactory has a member of type DAOClass which will be istantiated to the proper DAOClass type... In last analyisis the ObjectFactory will use always and only the retrieve() method of the interface to provide its clients with an object of a certain kind, isn't it?
Indeed, a generic ClientClass can use every DAOClass it needs.. I thought that every DAO Should have methods to access data typical of the related business class (entity), is it right? (I could have added also a "proxy" class like DAOFactory, with methods getDAOUser() etc, but I will do if I have time..)
What I still cannot really decide is:
1) Who are the ClientClass? Can e.g. a User call directly its corresponding DAOClass to get its attributes istantiated from the DB? I know somebody would say: Check the DTO pattern, but i honestly would like not to "bite off" too much and at the same time do something which respect principles of good (even if not perfect) Design...
2) I read in the sun webpage mentioned above (DAO) that the DAO can have methods like selectCustomersRS() which returns a resultSet. This is very useful when you need to retrieve all the customers eg to show a list in a boundary (JSP in my case). My question is: who should have the ability to parse this resultSet in order to print a table containing the records read from the DB?
I am using an architecture where a JSP page has a related bean which deals with the form data (I consider the couple jsp+bean a boundary), then the bean has a related Controller (Java, no Servlet and that is why i have 2 files as a boundary, the professor allowed us..:))...
3) Directly related to the 2nd: is it possible to merge the controllers in a way that, instead of being tied to their use cases (I have things like: InsertBill.jsp->InsertBillBean.java->C_InsertBill.java and then the various entity classes) they are responsible for conceptually related actions (eg: C_People, C_Bills etc)?
Again thanks a lot!
Bye
# 5
There's a lot here and I'm having a little trouble digesting it all. One thing I think might help you is to understand that the DAO generally should take a request and return fully populated objects.
So take you UserDAO for example. You might have a method,
User getUser(String userId);
So this method takes the userid, executes the query. Iterates over the ResultSet (in this case there should be one or zero rows) creates a user instance for each row and returns it.
Then you would also have an updateUser(User); method that would take the data in the User Object and write it back to the database.
I think this may address a couple of your questions. Does it help?
# 6
yes it does!:) i think i am now on the right way to face this part of the project!thanks a lot!if you can digest the other stuff, i'd be also pleased!:)thanks anyway!bye
# 7
> yes it does!:)
> i think i am now on the right way to face this part
> of the project!
> hanks a lot!
> if you can digest the other stuff, i'd be also
> pleased!:)
> thanks anyway!bye
You should probably try and rephrase the question. Perhaps you
should working on this and then reasses where you need help.
Your expectations are likely to be different than your real experience.