Re: Standard Design and Development Methodologies
Novice wrote:
A couple of followup questions if I may.
1. I'm pretty solid on relational databases, although not OO databases.=
I'm not clear on the actual purpose of "persistence layers" though. I
started to look at Hibernate a few years back but got sidetracked and
didn't get very far. Can you possibly summarize in a few sentences:
a. what a persistence layer does
b. how an OO database differs from a relational database?
This is a major topic. I'll hit some headlines /infra/.
...
What other OO language would be best to consider? C++? Smalltalk? .NET?=
(Hmm, I'm not sure if .NET is even considered OO....)
..Net isn't a language, it's a platform.
You might read Grady Booch or others on what object-oriented blahblah is ge=
nerally.
Don't get too bogged down there - skimming the TOC and a few paragraphs in =
each chapter in the bookstore will get you started.
Object-oriented is just a way of looking at things. Relational algebra (RD=
BMSes) is another, orthogonal way.
Object-oriented, as well explained by Booch and others, entails adherence t=
o certain principles, the number and name of which vary a bit between autho=
rs. Basically it's encapsulation and inheritance, component and layered ar=
chitecture, and a clean, well laid-out structure.
Encapsulation involves abstraction of the interaction between tightly focus=
ed types that hide their mechanics. You program to the interface <generica=
lly at times>.
Inheritance is a spice to use lightly.
O-O is at its best a synonym for really good modeling. Each type should be=
fairly simple - easier to do if you concentrate on its interface and not t=
he messy innards.
Unit tests are invaluable.
Good languages are C#, C++, Smalltalk (the progenitor).
Other languages to know are Lisp, Forth, Javascript, Python, Go, Prolog, C,=
bash.
Object-oriented databases are a dead end.
IMHO.
But SQL is really only for those who understand relations.
Relations are not objects.
And vice versa.
But they map to each other, with a lot of transformational infrastructure. =
The key is that the object and data ontologies are not the same.
I've done a lot of that - mapping objects to relations, or "object-to-relat=
ional mapping" (ORM).
The best way to do ORM in Java is JPA, the Java Persistence API. There are=
three standard, free products that give you that specification: EclipseLin=
k, Apache OpenJPA, and Hibernate. Hibernate comes with a weight of documen=
tation and culture from its pre-JPA days. Don't get sucked into that. Sti=
ck firmly with JPA.
OK, "best" is relative. You might be fine with just the Collections API, w=
hich you should master anyway. But to talk to databases like Derby or Post=
greSQL, JPA is wonderful. As long as you don't think of it as "talking to =
databases".
JPA gives you an object-oriented view of persistent information, hiding the=
relational sensibility from the program. It is about control of sessions,=
that is, 'EntityManager' lifetimes, and how durable to make object propert=
ies, not about data. The framework handles a subset of data manipulations =
opaquely to support that mapping.
Well, translucently, but learn the basics first.
--
Lew