查看: 17094|回复: 30

[精华] 我为什么学习Hibernate

[复制链接]
论坛徽章:
1
授权会员
日期:2005-10-30 17:05:33
发表于 2003-10-4 13:37 | 显示全部楼层
其实iBATIS也不错, 当然Hibernate好像更强大一点.
不过, 现在情况有变, Gavin投奔JBoss去了, 具说他是去作JDO team的头的.
而且他现在已经是JDO 2.0 expert group的一员了, 从长远来看, 我看好JDO

使用道具 举报

回复
论坛徽章:
1
授权会员
日期:2005-10-30 17:05:33
发表于 2003-10-4 22:24 | 显示全部楼层
奇怪!
谈点正经的, 怎么就没人了呢!
说实活, 这个贴子绝对应该标上"精华"什么的.
斑主, 在哪呢?
说得非常好, 很有感触...
上项目之前, 却是得三思而后行哪, 否则以后麻烦大了去了.

使用道具 举报

回复
论坛徽章:
1
在线时间
日期:2007-04-27 04:01:02
发表于 2003-10-4 23:57 | 显示全部楼层

The Serverside Interview with Gavin

Source: http://www.theserverside.com/events/index.jsp

Gavin King - Founder, The Hibernate Project

Gavin King is the founder of the Hibernate project, an ORM implementation for Java. He is co-author of an upcoming Manning book, 'Object Relational Persistence in Java'. Gavin lives in Melbourne, Australia, where he has been working as a J2EE consultant for several years, evangelizing open source solutions and agile methodology. He currently works for Expert IS.

Discuss this Interview



Gavin, can tell us a bit about yourself and what you're involved with?

I’m the founder of the Hibernate project. And at the moment I’m also kind of branching out a little bit peripherally into a couple of other projects, which are useful as part of the Hibernate toolset. (I've made) a couple minor contributions to XDoclet and Middlegen. I’m interested in continuing that kind of work at the moment, and keeping and pushing forward with Hibernate and working on that. I’m not interested in branching out too much in too many different things and neglecting those core things within.

How did Hibernate get started?

Hibernate started because I was trying to build applications with CMP as well with EJB 1.1 and I found that most of the time I was not trying to solve the business problem, not trying to solve the modeling problem but trying to solve workaround limitations with EJB and putting a lot of effort into coding stuff that was infrastructure related, that was not related to the business problem.

And in the end after all that effort, after all the lost productivity of working with entity beans, in particular, the resulting code was ugly, it was non-portable, it was non-reusable. It's not reusable outside of an application server, it’s not reusable with some other kind of different persistence mechanisms, it’s untestable. All these kinds of problems. We heard a lot at the conference (TheServerSide Symposium) about, and previously on TheServerSide community, about problems with entity beans and they’re real. They are real. People aren’t saying all this stuff because they’re bad at working with EJB; there are real problems and these are smart people who understand how to build Java applications really well who have been saying this.

What about EJB 2.0 and 2.1. Haven’t they alleviated some of these problems?

Yes, I believe it’s improved, but a lot of the fundamental underlying problem, which is the confusion of a component, which is a coarse grained thing, with a persistent class, with a piece of your domain model, still exists. Secondly, yes, EJB 2.0 is an improvement but we still have basic problems: Inheritance. I’ll talk a bit more probably later about problems with doing things like aggregation, and projection and some of these kinds of things which still exist. We need something that, a bit more, unifies the relational and object models and lets you work with both simultaneously, in my view.

Why do you think Hibernate has become so successful?

We’ve actually got a list of things on the Wiki like, a list of things, you know because I’ve thought a lot about this, like what makes an open source project become successful and take off, and we’ve got a list of things, but I think some of the most important things are: the ability to develop a real community to really interact properly with users, to establish the expectation with the users that, one if there’s a problem, it’ll be fixed, if there’s suggestions then they’ll be taken seriously. The idea that the community is kind of a nice thing surrounding this project that the users can feel proud of. If you develop a thing where there's perhaps too many smart people with too many really strong ideas that are conflicting, you can end up with a kind of a disagreement, and disunity. Disunity is fine, different opinions are great but if you want to develop an open source product you need a feeling of community, a feeling of doing things together.

Secondly: Documentation. So many of the great Java open source projects that are out there could be so much more successful, and so much better as a project if people took the time to take pride in the documentation. To me, it’s a matter of taking pride in your work. When you build something, don’t you want to tell everybody about it? Don’t you want to write about and document it? So people keep talking about how good the documentation for Hibernate is. That’s because we’re proud of it. We’re proud of what we produced and we want to get out there and tell people about it.

Thirdly, I think, and this is something that should be common to many open source projects; thirdly, we’ve come into this, I’ve come into this particularly saying, "I’m not an expert in persistence, I don’t know all the answers, I’m going to work through this, we’re going to work through this with the users and design something together that addresses their needs." Hibernate does things that I never thought would be useful. And some of those things are the best features. The users have come and said, "you know I what I would really do is this." So getting away from that idea of having experts design software, and rather have things evolve. I sometimes say, "how many people believe in a Command and Control economy? How will Command and Control also benefit the software economy?

What are some of these features you talk about, that have become the ‘best features’?

I think I was coming from the point of view of a Java developer. One of the funny things is I never had a great background in SQL and the kind of things people were trying to do with SQL, and with working with data as sets of data. And often when we look at Java Persistence, what we’re looking at is a problem of objects, and the way you work with objects is very individual, you've got an object and then you work with another object. Whereas there’s this whole other world in the database where we’ve got this very elegant model. The relational model where we work with sets of data. And we need to be able to work with both representations.

And I admit, I wasn’t thinking about these problems in terms of working with sets of data. But what’s come up through users asking, well I want to do this. What’s really crystallized is the notion that you actually need to be able to work with sets of objects. So you need to be able to maintain your level of abstraction of where you have notions like inheritance and properties and associations and you’re working with classes, and the names of properties of classes. But at the same time you need to be able to be doing aggregation, outer joining, nested queries, all those kind of things, grouping, ordering, sorting, all those kinds of things, with your objects. And that stuff doesn’t get done on the Java side, that stuff should be done on the database side.

I think you can look at some of the other specifications that compete with Hibernate; they’re not addressing that issue; that issue of trying to unify the two worlds. Often we talk about O/R as a problem of bridging or mapping and I don’t think it should be looked at as that, it should be looked at as a problem of unifying, being able to work with sets of objects.

What’s wrong with traversing object hierarchies through Java; why the need for queries?

Firstly, traversing object graphs is simply too inefficient when you’re working with a relational database, particularly when you’re working with a database that might be physically separated from the process. So if you’re work by traversing graphs of objects you’re inevitably going to run into the n+1 problem. I’m talking about a more generalized n+1 problem than what people know very well from BMP, but a more generalized problem where we fetch data piece meal. And that’s simply inefficient with relational databases. I’m not an expert on object databases but I suspect in the case of object databases they’re a bit more designed to cope with that method of data access.

And one of the problems that we’ve had is that object relational mapping is being perceived as a bit of a hack workaround and what we really want is an object database, and we’ve tried to apply object database APIs to object relational mapping. And that’s not going to work because a relational database is fundamentally different. The way you access data in the relational database is fundamentally different from the way you access data in an object database.

What are some of the ways you’re merging these two approaches in Hibernate?

The most important thing for us, the center piece of our effort is the Hibernate query language which is a minimal extension of SQL where we’re trying to create something as close as possible to what people already use, people are already used to. Select foo from yadda yadda yadda. They know what a relational query looks like.

I’m kind of ashamed to say that in the Java community, I think often, we look at that stuff and think it’s a bit dirty and people talk about persistence layers as being able to shield the developer from having to work with that kind of stuff. But if you actually sit down and spend some time thinking about the relational model and relational modeling, you realize it’s actually very elegant. What makes it dirty is the mismatch problem, is the mapping problem, that’s the only part that makes it dirty. What makes it dirty is working with JDBC and trying to map the stuff that comes out of JDBC onto a graph of objects. That’s what makes it dirty, not writing SQL, not working with SQL.

So, we have a query language that’s based in SQL, which I think is a nice language. It’s a very small language but it’s nice. We’ve tried to put object oriented constructs into that and we're continuing to try to do that.

Did you evaluate ODMG’s OQL standard and if so, what was wrong with that standard?

OQL's great and in some ways there’s a subset of Hibernate query language that’s the same as OQL. But OQL was based around object databases so we have notions like method calls in OQL and that simply doesn’t apply to object relational mapping. Secondly, we have the problem in a relational database, null equals null evaluates to null. And that’s not the case in an object database.

How about JDOQL?

JDOQL is a query language for stuff. It’s designed to be able to query some kind of transactional system like CICS or some kind of flat file or perhaps even XML format or potentially a relational database, certainly an object database. It’s not specific to any kind to any particular persistence mechanism and as a result, when you’re trying to work at that level of abstraction you simply can't add in constructs which are specific to relational mapping. A particular one is outer joins, but also things like aggregation. Aggregation and projection are essential things and our users use them all the time.

How do you deal with stored procedures?

Stored procedures are essentially a non-relational view of a relational database. They're a procedure oriented, a call oriented view of a relational database. So my view, and this is a controversy, not everybody agrees with it, my view, currently, is that the goal of an object relational mapping tool should be to map between tables and objects, not between objects and "some other stuff".

Having said that, many people are using Hibernate in an environment where they have some data access via stored procedures or via some other kind of heterogeneous means. So we try very very hard to support access to data that’s hetergeneous, that’s coming from different places or is coming out of the database in different ways. And the way we’re doing this is not by hiding all that behind Hibernate, because in the end we’re trying to do one thing and we’re trying to do that well. How we’re trying to do it is by simple things like exposing the JDBC connection that Hibernate’s using to the user so that they can go and do anything they like.

Secondly, by allowing hooks into Hibernate. For example, one of the great things about Hibernate is that kind of unified model types, model of types of a property of a class. And we have a notion or a custom type, where the user can build their own custom type for a property of an object. A custom type can be used to create an association between an object, which is persisted by DAO, that uses direct JDBC stored procedures, yadda yadda yadda, LDAP, and can then become part of the object graph that the Hibernate application's loading. So that’s how we’re trying to address those things, currently.

You’re obviously very passionate about transparent persistence but what I’m hearing from the major vendors is that their customers aren’t asking for it; they just don’t seem to think it’s important and neither do certain factions within Sun. Why do you think transparent persistence is important?

Firstly, to address the first part: that some vendor’s customers aren’t asking for that. Well, my view on that is that who are they defining as their customers? Are they defining their customers as the developers who work with their products day to day? Or are they defining their customers as the organizational people they go to when they sell an application? I don’t know the answer to that, but I’m raising that as a question, right. To me, it appears, the interest in Hibernate should demonstrate, that in fact, that developers are very, very, interested in the problem of transparent persistence.

Secondly, transparent persistence is important because, firstly it lets you concentrate on the business problem. And that’s very important. Transparent persistence forces the infrastructure implementer, or infrastructure vendor to not make you write too much code. A POJO is the simplest, in terms of LOC, the smallest object that you can write. And transparent persistence, saying that word forces us, as implementers of Hibernate to make sure that that’s all you need to write. So it’s important from that level. Secondly, it’s important from the level of portability. Code is not portable between EJB 1.1 and EJB 2.0 because the infrastructure gets its little fingers into the business model. Whereas the business model should be completely portable between Hibernate or JDO or Toplink. I might be making a bit too extreme a claim there, but potentially once you're talking about writing POJOs, you’re talking about building a system that can easily be ported to a new infrastructure. But also, a system that's easily testable, that's easily unit testable, a system that can run in a batch process or in some asynchronous listener.

And all that stuff's really important. For some reason reusability is seen as an advantage of EJB. But in fact the lack of reusability is the disadvantage of EJB. POJOs are reusable. Things which implement interfaces or inherit stuff simply aren’t as reusable.

One of the reasons why transparent persistence may not be getting as much attention is because a lot people just aren’t writing domain models. Why do you think people are not yet adopting such a good object-oriented paradigm yet?

Firstly, not every application needs a domain model. There are lots of applications for which a domain model is absolute overkill. There are lots of applications for which a view of sets of data coming out of the database is absolutely appropriate. And there’s all kinds of good tools in Java, in the open source community, for writing that kind of application well, things like the Spring Framework give you great ways of getting away a bit from very messy JDBC code, but writing those kind of applications which pull some stuff form the database and display it on the screen, or insert a row of data into the database. You don’t need a domain model to do those kinds of things.

On the other hand, there's a whole other class of applications where we do significant business logic. And I should come back and say, really that’s not all applications. One of the problems is that a lot of books you read about Java assume, push on people the notion that they need to abstract their business logic out from their presentation logic. But if you’re not doing sufficient business logic you don’t need to make that level of abstraction.

But there are some applications which need to do that. For those kind of applications, I think, unfortunately, because of the lack of a really good way of doing transparent persistence, that in itself, has pushed people away from using domain models, from using simple POJO-oriented domain models. One of the fundamental aspects of the domain model is it gets persisted to a relational database, in 98% of Java applications. Not being able to do that efficiently hinders the adoption of that way of building applications.

What were some of the biggest technical challenges you faced building a persistence framework?

Technical challenges are easy. The big problems are all social, communicational mainly. We have some algorithms of medium level of complexity that some business applications and a lot of other open source projects don’t have pieces of code which are quite that complicated. So we’ve got some algorithms and stuff going on that’s of a medium level of difficulty.

Trying to communicate to other people how Hibernate works, particularly how Hibernate works internally as opposed to semantics, the external semantics, the user visible semantics of Hibernate, it’s very, very difficult. When you’re not in the same room as someone, when you’re not able to communicate in words, when it’s even difficult to communicate with diagrams, your communication is limited to emails, text-based things and more than anything else, I’d love there to be a bigger number of people in the world who understand how Hibernate works. There’s enough now, but early on it was a real difficulty when I’m the only one who’s really able to understand that code. Things like Javadoc, and code comments can help all that kind of stuff but really to do that kind of stuff efficiently you need to be able to sit down next to someone and go, "Oh, this is how this works!"

Hibernate seems to have taken a strong stance against JDO. Why?

I’d like to think of it as, we’re not taking a strong stance against the notion of JDO. What we’re doing is we’re saying that we’re not going to implement JDO yet, because JDO has some limitations that would mean users simply would not use JDO, they’d use native APIs because they can do stuff with Hibernate that they need to be able to do, that they will not be able to do with JDO now. If possible, in JDO 2.0, which is an absolutely "up in the air" thing, nobody knows what it’ll be, what it’ll do, it is possible iJDO 2.0 will address these problems I’m talking about and then we’ll be able to move into implementing that. Another reason that we don’t implement it is because, now this is not an absolute show stopper from our point of view, but JDO specifies not only some user visible APIs, but also some implementation details. Now, there’s been an awful lot of discussion on TSS about bytecode processing, is it a good thing, is it a bad thing, does JDO really require bytecode processing, or can you do it some other ways with inheritance? There’s all kinds of complicated issues around that.

My position is that if you want transparent persistence, you need bytecode processing. Bytecode processing is not necessarily bad, but JDO doesn’t need to mandate it. So perhaps what we can look at is having two levels of compliance to the JDO spec. There’s the binary level of compliance were compiled POJOs are binary portable between different JDO implementations. And there’s another level of compliance where source code will be portable. And really, I don’t know where this problem of binary portability came from. I don’t know anybody who’s trying to solve that problem.

As far as I know people are very happy to have source code level of portability. It would also be nice if some of the requirements were loosened up so that you could have different implementations. Reflections are in implementations a great way to do transparent persistence. They’re fantastic. There is no reason why JDO can’t support both approaches. I believe we can change the specs to allow both those approaches without losing anything much. So that’s another level of reservation, but fundamentally, the main problem is that our users want to do things that they can’t do with JDO code.

What kind of things could be added to JDO that might get your support?

Okay, firstly, my number one issue is that in traditional ORM there are two ways of getting stuff out of the database. There’s the query by criteria style API and there’s the query language style way of querying. It's as if they (JDO) couldn't decide between the two models which are both good models and excellent for particular cases and they decided to do something a bit in the middle where they've married something that’s a bit like a query by criteria API to a sort of an expression language that’s sort of based around some Java syntax and I don’t know where it’s going. It doesn’t seem to allow easy extension into those kind of issues that we were talking about: aggregation, projection, outer joining. It doesn’t seem to be able to move in that direction. So this is the number one problem with the JDO spec, is that the query API is inelegant, I don’t think that’s going too far, and also it’s not clear how to extend it and add important features to it.

What’s in the pipeline for you and Hibernate?

Currently, we’ve just delivered Hibernate 2.0. I think that’s gone pretty smoothly. People now working have moved across from 1.2.x to Hibernate. There were a couple of little teething issues. I think it’s gone smoothly, now we’ve ironed out those and I think it’s going well. And this really does represent the culmination of a lot of work and a lot of ideas and now we’re a little bit casting around for things to do and maybe take a little bit of a break. The big thing that is immediately in front of us is distributed caching, support for some reasonably good transaction for distributed caching. And there’s a couple of things going around there. It would be really nice if they could get the JCache JSR out, but there are some other things we can do before then.

So what’s so bad about byte-code manipulation?

Nothing's so bad about bytecode manipulation. Bytecode manipulation's okay, if you need it. Particularly in the case of some of the AOP frameworks that are coming out where they want to do field level interception and all that kind of stuff. If you need to do field level interception, that’s really good, you're going to need to do that. Bytecode enhancement as part of the build process, to me, is a bit of a problem. It requires support in all your development tools or else it’s an extra step in your build cycle. Those are problems you can get past. My problem with bytecode manipulation in the JDO spec is that it’s required. Not that you can use bytecode manipulation to implement JDO, but that it’s required for no really strong reason.

What approach does Hibernate take?

One of the interesting threads of conversation that's been going on, that I’ve been involved with a couple of people, is this question of how to implement AOP frameworks, where you have what Rod Johnson didwas he wrote up a hierarchy of the ways to implement it where he started off with dynamic proxies and ended up with a new language like AspectJ. And in between there were these two options: here was bytecode manipulation which interestingly AOP frameworks are trying to do it runtime by hooking up to the application server classloader, so that was an option, but there was some questions about how easy it is to make that portable between different application servers when we don’t have control over the class loaders. I really don’t know the answer to this because I haven’t looked at the problem closely, but I know there was some different opinions flying around from different people.

But there’s another solution, which is what Hibernate is using currently for proxying, which is called CGLib. Now CGLib does a few things. It’s a library of useful things you would want to do with bytecode generation. So it solves some common problems, and in particular a couple problems that we want solved. CGLib lets you do some bytecode generation to load new classes. So this is a little bit more of a light weight thing than actually manipulating the classes as they’re loaded. CGLib will load a new class. And that’s the way we’re using bytecode stuff with Hibernate.

So we’re creating these proxies which are a bit more powerful than a JDK dynamic proxy. You can think of what CGLib's doing here as being a bit like an alternative implementation of a JDK dynamic proxy, except that it works on 1.2. Importantly, you can inherit a concrete class as well as implementing a list of interfaces and a JDK dynamic proxy doesn’t let you do that. So it means that we can implement proxies for things. Often in Java and all over the place in JMX, EJB, you see a pattern where we allow proxying and indirection, interception between the container and the implementation by having an interface and an implementation device and that’s required by the specifications because they want the container to be able to get in between the client and the server transparently.

Now, that’s not required with Hibernate because we have CGLib where we can do interception upon the methods of a concrete class and CGLib is what lets it do that. CGLib is something built on top of BCel and ASM, for people who are wondering how it relates to these other things.

使用道具 举报

回复
论坛徽章:
1
在线时间
日期:2007-04-27 04:01:02
发表于 2003-10-5 00:29 | 显示全部楼层

To Noddy

I do not think Gavin will transfer to JDO, at least before JDO becomes better.

Source:
http://www.mail-archive.com/hibe ... e.net/msg02374.html

[Hibernate] Hibernate + JBoss Partnership

--------------------------------------------------------------------------------

From: Gavin King
Subject: [Hibernate] Hibernate + JBoss Partnership
Date: Wed, 17 Sep 2003 08:48:01 -0700

--------------------------------------------------------------------------------
Hi everyone,

We will be making a major announcement soon, and I would prefer that everyone here learns about this development here, rather than in the press, or on TSS.

As you must realise, Hibernate and the Hibernate project have been created entirely by people working in their spare time, using donated resources. Development of Hibernate was never at any stage supported by any commercial (or nonprofit) organization, and the project never had any kind of income.

The people who have contributed code are all (I hope) listed in the changelog. I also need to single out Christian Bauer who, though his name does not appear there, has been essential to the success of the project due to his work on the website and documentation and many other thankless tasks.

Its also a good point at which to thank all our users for being one of the coolest developer communities on the Internet. Even when I'm a rude grumpy bastard answering forum posts at 3am, I'm always happy to see people using Hibernate.

The success of the project (and it is now a very successful project) has taken an enormous amount of time from my personal life. It is incredibly difficult to keep up with the huge amount of traffic in our forum, let alone find time for development, while at the same time holding down a "real" job.

Fortunately, we've now found a way to out.

JBoss Group will support the development of Hibernate, by hiring me to work full time on Hibernate, and on JBoss/Hibernate integration. In addition, myself and other members of the Hibernate team will now be able to provide commercial support and professional training through JBoss Group. This is something that many people have emailed me about, and I simply havn't been in a position to be able to do.


What this means for Hibernate users
===================================
* more resources for Hibernate development
* able to buy professional training / commercial support
* assurance that the Hibernate project continues to exist and grow


What the means for the Hibernate team
=====================================
* a chance to make some money
* Gavin gets his life back (maybe)
* no longer have to beg and scrounge for money for things like domains


What this means for the Hibernate project
=========================================
* more developers
* Hibernate will be distributed with JBoss application server
* lots more users
* an easier "sell" to management types
* we get a marketing team!

What this means for the JBoss project
=====================================
* JBoss will use Hibernate as backbone of CMP layer
* Hibernate will complement JBoss AOP, being a POJO-oriented persistence layer

What this means for JBoss Group
===============================
* JBoss gets a great persistence engine!
* lends credibility to jboss.org as an umbrella for more than just the appserver project
* JBoss is able to sell Hibernate training and support

What it does NOT mean
=====================
* Hibernate will not become dependent upon JBoss! It is a central goal of the project to remain platform independant!
* you will not have to start paying for documentation
* we will not stop giving great support in the forums
* Hibernate will not be "swallowed" into the JBoss project; it remains a seperate project, now affiliated with jboss.org and supported by JBoss Group
* our central goals do not change: we remain committed to building the killer ORM implementation for Java!

Just in case its not yet clear, this is great news, and is a huge coup for both Hibernate and JBoss! The future of this project is now guaranteed.

peace


Gavin King
http://hibernate.org

使用道具 举报

回复
论坛徽章:
5
ITPUB元老
日期:2005-02-28 12:57:00授权会员
日期:2005-10-30 17:05:33会员2006贡献徽章
日期:2006-04-17 13:46:34ITPUB8周年纪念徽章
日期:2009-09-27 10:21:222013年新春福章
日期:2013-02-25 14:51:24
发表于 2003-10-10 21:15 | 显示全部楼层
技术总是在不断变化,还没来得及研究CMP呢,却发现有许多更好的技术,看来要加快学习速度了。

使用道具 举报

回复
论坛徽章:
1
授权会员
日期:2005-10-30 17:05:33
发表于 2003-10-14 09:12 | 显示全部楼层
说正经的, 业界现在几乎不用CMP, BMP了.
Session Bean 倒是挺不错的.
现在的模式从SB+CMP+DB, 变成了SB+ORM(Hibernate, or JDO)了.

使用道具 举报

回复
认证徽章
论坛徽章:
55
生肖徽章:虎
日期:2006-09-06 21:14:232011新春纪念徽章
日期:2011-01-25 15:41:502011新春纪念徽章
日期:2011-01-25 15:42:152011新春纪念徽章
日期:2011-01-25 15:42:332011新春纪念徽章
日期:2011-01-25 15:42:56管理团队成员
日期:2011-05-07 01:45:082012新春纪念徽章
日期:2012-01-04 11:49:542012新春纪念徽章
日期:2012-02-13 15:11:182012新春纪念徽章
日期:2012-02-13 15:11:182012新春纪念徽章
日期:2012-02-13 15:11:18
发表于 2003-10-14 21:44 | 显示全部楼层
您所指的业界是什么公司?BMP用得倒是一向很少的。但是据我所知,至少在IBM,CMP还是大行其道的。倒是用hibernate的,我没听说过。当然,我所知道的公司比较少。

使用道具 举报

回复
论坛徽章:
29
ITPUB元老
日期:2005-02-28 12:57:00奥运会纪念徽章:赛艇
日期:2012-06-27 19:13:53ITPUB 11周年纪念徽章
日期:2012-10-09 18:03:322013年新春福章
日期:2013-02-25 14:51:24日产
日期:2013-09-09 12:38:53马自达
日期:2013-09-26 23:28:19马自达
日期:2013-11-20 14:52:01红旗
日期:2013-12-09 11:45:58一汽
日期:2013-12-14 13:27:442014年新春福章
日期:2014-02-18 16:41:11
发表于 2003-10-15 04:13 | 显示全部楼层
本还想插几句不过算了.CMP/EJB从一开始我就不看好.关于JDO和Hibernate,在TSS上倒是曾有过激烈的讨论,专家对专家,非常之精彩,同好不可错过.

使用道具 举报

回复
论坛徽章:
1
授权会员
日期:2005-10-30 17:05:33
发表于 2003-10-16 02:14 | 显示全部楼层
就目前来说, Hibernate要比JDO好, 可是将来就不好说了.
1. Cavin 已投入JBoss, 很明显Mark企图控制Hibernate, 而这是那些
  大厂商所不愿见到的, 这样Hibernate的推广应用就会打折扣了.
    虽然JBoss也是开源的, 但名声和影象比Apache就差远了.
2.  Cavin 目前已是JDO 2.0 专家组成员之一, 他还承诺Hibernate将要
  以JDO兼容, 或者是JDO的具体实现.

所以, 我认为JDO前景会更好一些.

使用道具 举报

回复
论坛徽章:
0
发表于 2004-6-25 09:45 | 显示全部楼层
Hibernate 在目前情况下的确是开源OR Mapping 产品中一个不错的选择,而且通过它可以比较容易地进入到ejb3.0, 不过其长远前景应该不如JDO.

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 
京ICP备09055130号-4  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表