ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Schatten <ala...@gmx.at>
Subject Re: Modeling objects - Best practices wanted ;-)
Date Sat, 30 Dec 2006 17:08:26 GMT
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





Mime
View raw message