Rick Reumann wrote:
They have to look at a database model in order to figure
out how to get back a dateOfBirth field?
Yup. Each develolper has a 24" poster of the data model. DBA is in
charge, Model Driven. Just like client server days.
Now
they want to iterate over this list and display some properties.
I use JXTable that needs a tableModel.
I wrote a class that extends tableModel that takes init(List)
In Struts, you can pass the List to DisplayTag, but you know that.
they'll have to look up the database model.
Yup. Each develolper has a 24" poster of the data model. DBA is in
charge, Model Driven. Just like client server days. Did you bring that
up again?
I'm just glad I don't have to
work on projects where I have to go to the datamodel to figure out the
names of my properties to use as a key in order to get out a property
from a Map.
what if you had...
if ( someCondition ) {
Integer age = (Integer)employee.get("DOB");
//other stuff
}
We almost never see class cast exception in practice.
> How does the developer know what "type"
was used for the value? I can look at a bean and see...
No type. Look, lots of developers are using dynamic langs.
I suggest you try Groovy one time, just play w/ it. Its
Better/Faster/Ligher J2EE.
Realy Rick, please try Groovy... it's the answer that's looking for you.
I am sure you have read some of the Rails press.
Double price; but I have not idea what type of value
shippingOrder.get("price") is. The developer just has to guess or where
does he look? The datamodel?
OK... I see your main point is that one has to memorize the data model.
In order to write good fast scalaeable querries.... you have to know the
model.
DBA is resposible for the data model. They tend to be VERY experienced
w/ production issues. So I leverage their experience over java
developers, most Java people tend to have less than 10 years prof. exp.
> Sure
if only one person has to deal with the code, it 'might' be faster since
he might simply remember all the types etc, but what happens when the
code is inherited? Pity on that developer.
Good theory that I used to beleive.
In practice, that is why I went from Beans to Maps. 10% of get/sets on a
project tend to be deprecated either becuase of model changes or becuase
of view changes.
W/ a Map:
- you don't have VO/DTO classes, but still have layer, 0 code, 0 bugs
- It's dynamic, when DAO SQL string changes... so does your
jxTable/Displaytag.
I removed an entire layer and still have the layer.
Developers are so pasionate... that's what makes them good.
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
