Hi
The current approaches with PGObject etc are a little limited and I am in the process of porting them to Java (and maybe Python after).
I would like to propose the following changes to the framework going forward.
1. Would like to refactor PGObject,pm to make the registry a separate Perl module. This would lead to better separation of concerns.
2. Annotations would be used to identify what properties to use. Moo and Moose Perl modules would be used to introspect the annotations but the service locators would be applicable as both roles and parent classes.
3. Service locators would provide association to database connections, and API's for associating one object with another's db connection or directly, manually setting it. The current lookup would then be a default only, where we have no parent object and a standard means of passing a db handle into a method call would be supported and documented.
4. In the Java side, we would use public field variables, with final applied to all ones which are not expected to be given a default value on save. A constructor would need to accept a map<String, Object> for instantiation.
5. DBMethod code is a bit clumsy at present. I would like instead to make an attribute hander, similar to the way annotations are used in Spring.
Proposed Perl code approaches/snippets:
has 'id' => (is => ro, dbattr => 1, isa => 'Int');
sub get :dbmethod {
return { name => 'get', as_object => 1,};
}
Similar Java code might look like:
public class Company {
public int Id;
public final String ControlCode;
public final String LegalName;
public final int CountryId;
public final int EntityClass;
public Company(int Id, String ControlCode, ....){
....
}
public Company(Map<String: Object> DBRow){
return Company(
DBRow.get("Id"),
DBRow.get("ControlCode),
....
);
}
};
Any thoughts or feedback?
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.