T
timasmith
So, I feel I am close here is what I have so far.
Goal: Database driven selection of controls on forms
Goal: Business rules only aware of interfaces
Goal: Presentation layer only aware of interfaces
Database Table Person: Name, BirthDate, Gender, CreateDate, CreatedBy
Value Object:
public class Person {
private String name;
private DateTime birthDate;
private int gender;
private DateTime createDate;
private int createdBy;
}
Business Layer Object:
public interface IPersonModel {
public boolean isTeenager();
public boolean isMale();
public boolean isFemale();
}
Presentation layer Multi Column List control
public interface ITableList {
public int rowCount();
public Object getItemAtRow(int row);
public Object getValueAtRowColumn(int row, int column);
}
public interface ITableItem {
public Object getValueAtColumn(int column);
}
The most complex part is storing in a database table which fields on
the value object will be presented in the multi column list control.
It needs to be user friendly and maintainable.
One time I tried having each value object with a switch statement for a
unique number for each field. So the database contents and source code
are kept in synch e.g. 266 in the database means 'Person CreateDate'
and the value object returns that when implementing ITableItem.
It worked but relies on a code generator to make it all work.
This time around I thought I could keep a script in the database so the
user would pick the first column to be person.getCreateDate(), the
second to be person.getName() etc.
Using reflection I could generate on the fly which attribute will be
displayed in which column.
Anyone think of other options?
The other thing I need to change is it seems an unecessary dependency
for the value object to implement ITableItem - there probably needs to
be another class which does it and depending on the database values
pulls the data from the value object.
The same goes for the value object implementing the business rules.
While probably not too bad if it does, perhaps mapping the values to
something that does might work better.
Apart from the value object I am trying to anything else in all the
code knowing about fields which are only used for CRUD e.g. createDate.
CreateDate may never be used for logic - in my app - ever - so why
pass it around as business objects - better to only have things
implementing interfaces where needed.
What do you think so far?
Goal: Database driven selection of controls on forms
Goal: Business rules only aware of interfaces
Goal: Presentation layer only aware of interfaces
Database Table Person: Name, BirthDate, Gender, CreateDate, CreatedBy
Value Object:
public class Person {
private String name;
private DateTime birthDate;
private int gender;
private DateTime createDate;
private int createdBy;
}
Business Layer Object:
public interface IPersonModel {
public boolean isTeenager();
public boolean isMale();
public boolean isFemale();
}
Presentation layer Multi Column List control
public interface ITableList {
public int rowCount();
public Object getItemAtRow(int row);
public Object getValueAtRowColumn(int row, int column);
}
public interface ITableItem {
public Object getValueAtColumn(int column);
}
The most complex part is storing in a database table which fields on
the value object will be presented in the multi column list control.
It needs to be user friendly and maintainable.
One time I tried having each value object with a switch statement for a
unique number for each field. So the database contents and source code
are kept in synch e.g. 266 in the database means 'Person CreateDate'
and the value object returns that when implementing ITableItem.
It worked but relies on a code generator to make it all work.
This time around I thought I could keep a script in the database so the
user would pick the first column to be person.getCreateDate(), the
second to be person.getName() etc.
Using reflection I could generate on the fly which attribute will be
displayed in which column.
Anyone think of other options?
The other thing I need to change is it seems an unecessary dependency
for the value object to implement ITableItem - there probably needs to
be another class which does it and depending on the database values
pulls the data from the value object.
The same goes for the value object implementing the business rules.
While probably not too bad if it does, perhaps mapping the values to
something that does might work better.
Apart from the value object I am trying to anything else in all the
code knowing about fields which are only used for CRUD e.g. createDate.
CreateDate may never be used for logic - in my app - ever - so why
pass it around as business objects - better to only have things
implementing interfaces where needed.
What do you think so far?