My RSS Feeds
We're really not as smart as we think we are.
Of course, I'm also on the other side of the fence, and I've been using hibernate, and I have my own DAO framework that I've been known to put here and there, and I'm certainly unafraid of JDBC or XML, and I've even been thinking of looking into JDO.
I think the willingness to advocate entity beans is the most controversial, though, what with everyone and their brother (and their brother's friend's cousin) being happy to publicly whine and moan about what a pain EJBs are. "Sure, session beans are okay, especially stateless, but entities are awful!"
I still disagree. I think CMP beans are a stopgap. They're okay if your data is coarse enough (or you have few enough entities) but generally, people tend to look at them as if they were the equivalent of a persisted class in hibernate, which just doesn't work. On the other hand, since they're abstracted out at the container level and not the classloader level (as hibernate's sessions are), you get a lot more flexibility out of them, despite having to actually configure them.
BMP entities are where it's at, if you ask me. Sure, more work, I guess, but you get the benefits of the EJB classloader layer plus server-level caching and distribution. Hibernate can give you these things, but you end up investing enough work that you might have been better off just using EJB in the first place. Zealotry is really cute when it makes you do more work.
I think the biggest problem is that Java programmers have never escaped C's idea of deliverables. In C, you compile, and booya! You have a deliverable. In Java, for applications, you compile, and booya! After you create a jar, you have a deliverable. (Or something like that.) It's as if Java programmers, having broken from C, still long for that trivial deliverable process for enterprise applications.
This is a mistake, in my opinion. The J2EE specification takes pains to say that deployment isn't the same as compilation, so much so that deployers have their own place in J2EE. A programmer often serves as his own deployer, which is necessary if he's going to test (and everybody tests, right?) so the natural tendency is to get upset that deployment is a separate step.
So since people get upset that they have to "switch hats," so to speak, they spend a lot of time and energy creating ways in which they won't have to switch hats - switching hats at compilation time, for example, instead of at deployment time.
This isn't so good. It means that the choices the developer makes end up affecting the enterprise. That's fine when the choices aren't critical... but they often are. Humans are shortsighted. My choice of a database column is fine for local development, but at the enterprise level... maybe it matters, maybe it doesn't. If I'm wearing two hats instead of trying to force them into one, it's okay - the deployer can fix the column name at deployment, I can use MY column name during development, and my deliverable doesn't change.
I don't mean to run down Hibernate. I'm using it myself, right now, and I'm not unhappy with it. It's just that Hibernate pushes the decisions over to the developer, and I don't think the developer is the right person to make all of those scalability decisions.
Uhm, what exactly do you have to do in Hibernate to get "server-level
caching" and "distribution"? I think you got it from the wrong end. There
_is_ a good point for the 2.1 entity bean model: its closer to the
relational model. Yes, thats true, it is more table-oriented ("coarse
grained" if you like), it supports the same relationship semantics as the
relational model (CMR is very close to FK constraints) and was apparently
invented to bring both models and concepts closer by moving relational
views into the application layer.
We know from experience that this approach didn't have much success. What is now happening with Hibernate is that we try to use more object-oriented concepts and best practices (all pretty vague, but OO developers are used to fuzzy terminology) to move both realms closer together. We'll see how that works out.
Stuff like caching, distribution, transactions, etc. are pretty much the same in all cases, i.e. they are orthogonal to the real problem.
Christian Bauer [christian@hibernate.org]
The EOM for most mid-to-large level projects is essential. I think
Hibernate is perfect to get a project off the ground quickly.
Would I choose hibernate in my next project ? Unless there is a reason not to (crazy schemas - whatever) I probably would. However, will I want to select CMPs or BMPs ? Probably not. Why? It is still hard to find developers who *really* understand Entity Beans. Besides I don't care about the life-cycle or distribution of entities. I would prefer a simple OR mapper that does the trick.
What would I do if hibernate generated sql queries don't
scale? There are many ways to optimize...use DAO, FastLane whatever works
...
Scalability issues can be dealt with selectively (cross the bridge
when you come to it). It is pretty hard to figure out scalability issues
(unless they are pretty obvious) at development, compile, or deployment
time. I feel the scalability testing plays a major role (a non-J2EE role :)
in uncovering such issues.
I’m still not convinced that a true J2EE
deployer really exists. If someone knows how to write a build script does
not mean that person is a deployer. Knowledge about how components fit in
is cruicial and as project size increases – it’s a super-human effort to
know it all – all the time : )
I think most developers really don’t care much about scalability (or other non-functional requirement) when writing code (unless a software framework demands it). In this scenario switching hats can come naturally enough...because there is no hat - when you unit test you're still a developer writing code...
When easy to use development tools / IDEs are selected, much of hat-switching (between developer and deployer) becomes transparent . You write your "program" and then "start the server"....
In fact, developer probably never wear a deployer's hat. (its debatable if that's a good thing). A lot depends on team composition - Maybe scalability etc is best left in the hands of experts and the experienced.
Given that - a layer of abstraction is a *must* for J2EE development (between development and deployment)– if not – it can hit productivity big time – IDEs like WSAD do a nice job of abstracting away the deployment aspect at development time.
Rohit [rohit.sood@libertymutual]
I've got a vague feeling now that basically most of what I write can be as
well deployed as an EJB, with all the paraphernalia, session facade, and
the like. If, say, I have a project xml file, the data access should be a
BMP, and the accompanying functionality should be a session facade. Many
people advised me otherwise: too complicated to deploy, etc. It may be
complicated to setup, but once you do, you have a strange feeling of
getting out into a huge world of opportunities, easy and loosely-coupled
integration, etc.
So, yes, I concur.
Vlad Patryshev
I think any defence of BMP is pretty unsustainable. The BMP model is quite
broken, being thoroughly vulnerable to n+1 selects problems. It's pretty
much impossible to write efficient BMPs. (Unless you can cache your entire
database in memory, that is.)
Gavin
I've dumped hibernate for this https://jdbcpersistence.dev.java.net
dude
Re: I've dumped hibernate for this
https://jdbcpersistence.dev.java.net
Why?
ct
R V [rsv29@noyahoospam.com]
think the biggest problem is that Java programmers have never
escaped C's idea of deliverables. In C, you compile, and booya! You have a
deliverable. In Java, for applications, you compile, and booya! After you
create a jar, you have a deliverable. (Or something like that.) It's as if
Java programmers, having broken from C, still long for that trivial
deliverable process for enterprise applications
I think
you are mixing up issues here. What have entity beans got to do with the
convuluted J2EE deployment process. Also , if you would look at some make
files you would realise that the build and deploy process was anything but
trivial.
What C did well and IMO Java/J2EE fails is that, C allows you
to do simple things well. In the name of 'enterprise applications'
,whatever that may be , J2EE makes simple thing complex. And no I don't
find it fun to wait 10 minutes while the app server comes down and starts
up and the app gets deployed so that I can test a small change. Doing that
40 times a day is frustrating.
RV... The convoluted J2EE deployment process has EVERYTHING to do with EJBs
and the separation of components from clients.
And if you're waiting ten minutes for your app server, might I suggest getting a better app server? Mine takes a few seconds at most, if I decide to do a full restart.
Re: "wait 10 minutes while the app server comes down and starts up and the
app gets deployed so that I can test a small change"
Dude - if you're using that approach to test small changes then you've only got yourself to blame. In general it is possible to test most components outside of a container. Unit test will save you this wait.
ct
ct
I'd be interested in hearing your arguments on BMP over CMP -- I've heard
that before, and never seen anything compelling on the subject.
And while I can imagine that there are a number of times in which deployments are not taken as seriously as they need to be, I have to take issue with something that impedes the development process. I'm all for allowing for extensive configuration by the deployment team, and for that to be done with foresight and planning, but if that means that my compile and test cycle requires a slow process of planning and configuration for each deployment, that's not kosher with me.
I believe the real reason why entity beans draw the kind of apathy from
developers is because they are not as directly and easily comprehended as
session beans. The n + 1 retrieval problem is just a usage
restriction.
Niranjan
Niranjan Sathe