> http://weblogs.java.net/pub/wlg/971
>
> Just wanted to point out what java developers are really
> thinking about in regards to EJB-CMP, perhaps to show that my
> idea that the spec approach doesn't necesarily produce
> something people want. True even when the spec is widely
> implemented, and in particular in regards to EJB-CMP.
Interesting read :)
Some people disliked the concept of EJB however I got the
feeling more people disliked a set of details in EJB than the EJB
concept as a whole.
But indeed an example that a spec can work against you.
> Between the discussions on this list and discussions I had at
> a workshop in Malmo, I am more intrigued than ever about OR
> in .net, but I think the question remains open about what the
> best way to do it really is.
Oh definitely true. The O/R mapping world is very divided on the
subject what drives what: relational model drives classmodel or
classmodel drives relational model? And what you said in another mail,
the legacy situation demands sometimes that you only can write glue code
between an existing class tree and relational model which both can't
change.
However I don't think all of these things really matter much, as
they're more politics. I mean: if you want the class model to drive the
relational model, you need just 2 tables: 1 with 2 fields: a blob field
where teh serialized object is stored in and a PK field of type GUID and
a table which contains the relations between the objects. Of course this
is very simplistic but IMHO it illustrates the difference between OO and
the relational model so if you want true OO all the way, you have a hard
time projecting that OO hierarchy on a relational model, and you're
better of opting for an OO database.
To me the biggest issues which need standardization and
addressing by the platform supplier are:
- standarized object query language. This is not necessary for the
platform, but it is for end users
- generic platform for cross appdomain object awareness. This is
required so entities can be safely cached in one appdomain and used in
another, for example in a desktop application which targets a single
central database.
- generic platform for persistence end-points. This means that the
persistence logic is plugged into this framework, while the developer
sees just the framework. Like in EJB-CMP where the container (to my
knowledge) takes care of teh persistence, not the developer. This not
only gives the persistence vendors a common playground which guarantees
consistency, it also gives safety for the developers using these tools
so it's not a risk to opt for persistence framework ABC over DEF because
you're not really committing to a very vendor specific approach.
I find these points far more important than the detailed
nittpicking discussions about the fact if a 3 layer class hierarchy
should be persisted in a single table (halpin/nijssen supertype-subtype
flattening) or in 3 different tables linked to eachother with 1:1
relationships.
FB
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
Some .NET courses you may be interested in:
NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnetls
View archives and manage your subscription(s) at http://discuss.develop.com
