Larry Meadors wrote:
Holy crap that *was* a long email.
yes, I am very sorry for tha *g*
some additional questions, if I may :-)))
So far, so good. I always feel warm and fuzzy when people design the
database first. :-)
I do not know: I am very conservative to that respect, I feel, that the
most precious thing in todays world is (consistent) data, not programs
or objects, and this is why I start like so. moreover I find it easier
to play around with a data model, fill it with test data and stuff. this
is also why I could never really get warm with systems like db4o as
interesting as they are indeed!
Hmm, OK, problem #1: can a person exist without a project? Can a
project exist without a person? If the answer is ever yes to those, I
would not create my objects like that. A person is one thing, a
hm... have to think about this. however, I am not sure if this argument
is really striking; a list can also be "NULL" moreover, the connection
is potentially here, so...
Lazy-loading rhymes with lazy-coding for a reason: it is what it is.
When you are writing an application and you need a person object, you
know if you will need a list of the projects for that person or not.
If you need them, get them, if you don't need them, don't get them.
Well, but this has consequences! this was the reason for my example: I
would, e.g., want to know the persons of a project and vice versa; now:
when I retrieve one project instance, I would (according to your
suggestion) also retrieve the list of persons associated. that is fine:
but now comes the problem: these person objects also have lists for
projects and so on (the recursive issue). What to do? keep the lists
NULL? but then this is really bad too! because then I have to know (in
the business objects) where a person object is coming from: when it was
retrieved via project, it might be NULL in projectslist because of
loading, not because the user is not associated to any projects. this is
really fishy. here comes in the concept of lazy loading, no?
However, the clear drawback is, that we do not use OO "features" at all
and this is just a bunch of flat transfer objects then without obvious
references.
OO is a tool, not a goal.
yes, for sure, but we use OO models for good reasons: object hierarchies
help us understanding how entities are related plus they allow easier
navigation within connected objects.
OK, so to recap my opinions on this are:
1) Design your database first. If it's right, the object model will
fall in line.
2) Make data-access fine-grained, then let your service layer pull
them together.
3) OO is a tool, not a goal - use it if it makes things easier or
better, not because you need it to be cool.
If you need to have a Person with a list of projects, you can easily
create an aggregate object:
PersonAndProjects{
private Person person;
private List<Project> projectList;
}
You can even use the groupBy attribute to get that object (or even a
list of them) using only 1 select statement - super fast.
yes, this is an option I too I have to consider.
however, I still feel not very comfortable. What is your idea about my
accessor idea (accessing the DAO on "getProjects" method in the Person
object for example)?
thank you very much for reading my long email and giving me your ideas.
However, I would really appreciate it very much, if I could get some
more opinions?
thank you very much, and have a great 2007
Alex
