Review Rashid's works:
class Person<2.0> {
private String firstName;
private String surName;
}
class Person<1.0> {
private String firstName;
private String lastName;
}
Next step?
Separate, then later weave.
this means
+ We seperate when design --> yield easier design
+ We weave when use --> it must be complex enough to serve all business logics
+ Modification to EJB3 should be great (it's same to OODBMS, dont care RDBMS layer)
Why?
+ It's not possible to change all RBMS invesment to OODB
+ It seems that implementing virtual databases over the tranditional RDBMs is better
+ A virtual database (in my case OR/mapping - Hibernate, Ejb3) can be fully applied with AOSD
+ class versioning schema manager (Rashid 2002-2004)
+ annotation
+ concern
+ data alignment concern
This is an idea for separating Object and Relation concerns:
// teacher data concern
@Entity("Teacher", "1.0")
class Teacher {
private int teacherID;
private String firstName;
private String lastName;
}
@Entity("Student", "1.0")
class Student {
private studentID;
private firstName;
private lastName;
}
// separate advisor concern
@Entity("Teacher", "2.0")
class Advisor {
private List adviseeLists;
}
// separate advisor concern
@Entity("Student", "2.0")
class Advisee {
private Advisor advisor;
}
Teacher t = entityManager.load(Teacher.class,
new Integer(1));
Advisor a = versioningManager.morph(t,
Advisor.class);
This is a new idea for field substitution
How the developer access this code?
possible answer: IoC?
@Version(2.0)
class Student {
@Substitute(version="1.0", name="lastName")
private surName;
}
class StudentDAO {
public Student findById(int id) {
// codes go here ...
}
@Conform("th.ac.sut.ent.Student", "2.0")
public static void main(String args[]) {
Student s = new StudentDAO().findById(10);
// not found, throw exception
System.out.println(s.getLastName());
// should be ok
System.out.println(s.getSurName());
}
}
