m******t
发帖数: 2416 | 1 观点不同可以讨论,可以摆事实,搞得象文科傻妞一样拿"it's a joke"
或者"you don't know anything"来做挡箭牌就不但没劲,而且徒显虚弱
而已 -- 如果我的论点如此可笑,你作为一个有很多"hands on"经验的专家
应该很容易用事实驳倒才对,你有工夫写四五个帖子来反复声称我完全
不懂,但却忽略我每一个回贴的大多数具体论点,也举不出一个事实来具体
反驳我引用的东西不对,也说不出来你认为更好的办法有什么,到底谁是
joke,不是很明显的吗?
EJB搞了这么多年,一团乱麻.EJB 3.0的改动根本不是什么小修小补,而是
基本结构的变化,还兼并了JDO (JDO的制定本身就是受到hibernate和TopLink
这些ORM产品的很大影响),这就说明大家都认识到EJB 2.0以前的东西根本不
对头,非要有根本改变不能解决现在J2EE在结构上碰到的问题. 而EJB 3.0现在
所提议的改动很多都是从象Hibernate或者Spring这些项目来的,比如新的IoC
支持.这就说明这些项目走的路子是对的,或者至少不会比现有的EJB差. |
|
d****s
发帖数: 30 | 2
You always make me laughing...if JDO has a parent, no matter the
parent is ADO/ADO.Net. "JDO的制定本身就是受到hibernate和TopLink
这些ORM产品的很大影响", ha ha ha ha |
|
g*****g
发帖数: 34805 | 3 大部分系统select语句占一半以上，这样如果使用ORM在app server上cached数据，
速度就会快很多，包括你的join操作，并不一定到达数据库，所以是可以
减轻数据库压力的。另一方面就是达到了批量执行，也能快一些。
当然如果瓶颈还在db上，当然是没有办法的，只能cluster db。 |
|
m******t
发帖数: 2416 | 4 Well, to be fair, actually we do get locked into Spring, too, if you go
beyond the IoC container - transaction, ORM, etc. I guess the lock-in is
mostly a non-issue (to me at least) only because Spring is OSS and its
flexible Apache License.
Agree with your other points - in general, Spring rocks. 8-) |
|
c*m
发帖数: 836 | 5
Looks like I will die with Struts :). Still on struts now. I managed to
replace the home brew ORM with Hibernate ever since taking this position a
few months ago. I heard a lot good things about Spring MVC, but there's
simply no resource to convert the existing project with tight enhancement
cycles.
I don't quite understand JSF as a standard. Is there other vendor
implementing JSF aside from Sun RI and MyFace? |
|
c*m
发帖数: 836 | 6
In addition to goodbug's list, a few other books I found very good:
General JEE
Expert one on one J2EE Design and Development
J2EE development without EJB's
two classic books
Pojos:
Pojos in Action -- Spring, ORM, and designs. A very good book worth reading
many times
Patterns:
Patterns of Enterprise Architecture -- great book if you are interested in
lower level patterns and developing frameworks
Web Service:
SOA using Java Web Services -- with many many details and source code, a bit
hard to |
|
t*******e
发帖数: 684 | 7 struts1一周就能学会，目前流行的web frameworks, JSF, STRUTS2(webwork2),
Spring MVC, Wicket.都很容易学的，难的是Hibernate/JPA。ORM是最难写好的，也是
对系统performance影响最大的。 |
|
n*w
发帖数: 3393 | 8 那个typed dataset甚至都不能说是个orm吧。只是想听听对于很简单的applications用
这些除了学习的好处，还有没有什么? 如果要花3倍多的时间（对于crud的应用）？ |
|
S*********t
发帖数: 78 | 9 我看到很多人都是从数据库来生成domain object(entity)和 xsd ,然后用在web
service 数据传递。
可不可以先写 domain objects 然后用这个object 生成 xsd 呢？
感觉第一种方法 OO 不够好，是以数据库表为驱动的。
大家怎么看这个问题？ |
|
g*****g
发帖数: 34805 | 10 在我看来，web service只是remoting的一种方法，应该对xml透明。
用CXF之类的生成相关的wsdl即可，具体内容不必关心。 |
|
t*******e
发帖数: 684 | 11
要看是先设计数据库,还是先设计object model,我做的几个项目用hbm2ddl从object
model生成relational schema.和DBA的沟通很重要的,有许多实用的auditing columns
一般Java programmer不会想到。 |
|
t*******e
发帖数: 684 | 12
我开始的想法和你的类似。但实际上WS已经发展的非常远了。
Object centric web services比较合适企业内部使用，原因是简单，xml透明。但当通
信要跨越corporate boundaries 时，document centric (contract-first) approach
更合适些，这种情况下，method (operation) binding就被忽略了，所有的信息都包含
在XSD之中，包括具体的operations,transaction, security,policy等等。
修改一下，所有的信息都包含在XSD之中，以及SOAP headers里面。 |
|
m******t
发帖数: 2416 | 13
approach
+1. Any application serious about interoperability has _got_ to
start with the schema and wsdl. |
|
m******t
发帖数: 2416 | 14
columns
I always generate a draft DDL from the object model, but always
hand-write the final version (working with DBA as you pointed out).
I know the trend is to generate one from the other, but I think
for any non-trivial application, it's really worth it to hand roll
the object model and the db schema, considering how incredibly
critical they are in the entire architecture. |
|
g*****g
发帖数: 34805 | 15 I am not smart enough to design a better framework. But based
on my experience on Hibernate (which implements JPA too).
In the future we may have Object database as standard, until
that happens, ORM is the way to go. And I think it's simple
and powerful enough, the performance is battle-proof
modify |
|
s******e
发帖数: 493 | 16 Actually this is a good question.
Rule of thumb: no ORM should be used for bulk load. |
|
B*****g
发帖数: 34098 | 17 let me google ORM first. |
|
c*m
发帖数: 836 | 18
用不了好几年，入门最难，入门之后就会发现这些技术其实就是多，要花好多时间看，
其实都没什么难度，尤其是EJB3，现在更简单了。学这些东西，不要一头扎进一个里面
钻的太深，要先掌握好big picture，才不会有云里雾里的感觉。servlet那是基础，一
般也是直接和client交流的，建议你好好看看，那本head first servlet and jsp入门
不错（这是我觉得head first系列唯一值得看的）；EJB 和 Spring都是business
component container，其实最早的概念是EJB，至于为什么出来spring这么个东西，一
大堆的背景故事，你现在也不需要知道，就记住他们可以在servlet后面，进行主要的
business logic, 也是你的domain model存放的地方，当然spring还提供了一堆挺不错
的utility method；Hibernate是所谓的ORM，就是把object和relational db映射的一
层，你可以把它想象成在business logic和database之间，也不是所有的app都需要这
一层 |
|
c*****t
发帖数: 1879 | 19 No. You misunderstood what I was asking.
The issue at hand is not query optimization. But how to fetch
data efficiently. For instance, outer join let you retrieve
parent and child (assuming 1-1) in one single select statement.
However, if there are multiple children of the same type (1-many),
then such selection may not be efficient. Without outer join,
other approaches (without server component) would require multiple
selection statements.
This is a known issue for ORM tools. However, I ch |
|
F****n
发帖数: 3271 | 20 I guess at the level of hibernate (or other Java ORM tools), you have to
either use table join or multiple select statements because you have no
control over the underlying DB.
However, you can set fetch type in hibernate, for example "eager fetch"
would probably use on select with join and "lazy fetch" will create the
object for now and use another select to fetch the data when necessary. |
|
s******e
发帖数: 493 | 21 Hibernate does provide 'bulk' retrieval with join. in such case, it will
allow you to retrieve, for example, 10 people and their past work places
with one single db hit. But you should bear in mind, that no ORM is designed
for bulk operation, so you should to try to not use this feature. If it is
absolutely needed, you should always limit the number of records you want to
retrieve for one db visit, for example, you want to return only 9 other
persons if you want to get information about smectite |
|
F****n
发帖数: 3271 | 22 I think it can only be done with some DBMS extension. However, before you do
that, you should realize this is NOT new stuffs. OODBMS has handled that a
long time ago. It's a shame that fat cats in big companies turned down
OODBMS, and that's the reason today we need those stupid ORM stuffs. |
|
m******t
发帖数: 2416 | 23
Not sure about the equivalent annotation. I don't use those for
OR mapping.
That's certainly another way of doing it. I like the where approach
because I feel it's a bit of an overkill to introduce
different classes only for filtering purposes - kind of like bending
the OO design backwards to fit into the ORM tool. But it's really
a personal taste thing I guess. |
|
t*******e
发帖数: 684 | 24 Just call the flush method explicitly, assuming the app has Hibernate/JPA
running underneath. ORM solutions always defer database commit to reduce IO and improve performance. |
|
g*****g
发帖数: 34805 | 25 No, you have to use hibernate or JTA or another ORM solution. |
|
g*****g
发帖数: 34805 | 26 This doesn't neccesarily cause performance issue. From web tier point
of view, you want to get a fresh copy of DB object in every request,
that's a valid requirement in most applications, and caching shouldn't
be done in web tier.
You can always configure caching on DTO between either web/service layers,
or service/persistence layers. And these objects become application scope
immediately. Also these caching can be distributed so clustering is not a
problem. When you are using it with ORM, it ca |
|
g*****g
发帖数: 34805 | 27 If you just need an ORM on client side, you can use hibernate directly
or use spring to hook up hibernate, both should be fine.
java |
|
g*****g
发帖数: 34805 | 28 There are quite some reasons you may want to use spring container
in a thick client. Below are just a few
1. IoC, if you are talking to a server, you may find this handy,
inject services to your client is cleaner than passing the references
everywhere or use a hand-write factory.
2. persistence access helper, spring provides some ORM helper and JDBC
helper which can remove some boilerplate code and help you configure
transaction boundaries.
3. Access to other 3rd party api. If you use ldap, web |
|
g*****g
发帖数: 34805 | 29 Why don't we just use object DB instead.
I agree DB schema is just for optimization.
I would like to see ORM, or any object-storage mapping
is implemented and optimized in database. And I believe
that will be the case sooner or later. |
|
F****n
发帖数: 3271 | 30 Because in an open domain, you cannot assume you know the structure of all
your objects. Such structure may be extremely expensive to learn and very
difficult to maintain. And you still want to index some properties that you
are sure about. Just imagine that you only need to index on 5 properties, it
is pretty easy to extract these 5 from all objects and throw others to
serialization. On the contrary, it will be unnecessarily difficult to
develop an ORM for all objects, not to mention the much h |
|
g*****g
发帖数: 34805 | 31 I understand that DB is not smart enough and I don't mind giving it
some hint. e.g. Add an annotation on domain object to index certain
properties. But I'd like to see ORM, plus schema, plus most of EJB3
annotation being maintained automatically by Db.
you
it
for |
|
m******t
发帖数: 2416 | 32
Err... I thought the whole point of having an ORM is to abstract away
the database? |
|
F****n
发帖数: 3271 | 33 10 years ago there was this idea called "persistent programming" where every
object can be persistent and managed by an OODB. The idea as well as OODB
was rejected by mainstream. That's why we have Object Relational MAPPING
instead of direct Object Persistence Model.
It's interesting that people are trying to use ORM to re-create those
features. Personally I don't think they will be very useful. |
|
m******t
发帖数: 2416 | 34
every
IIUC, the reason OODB never really took off was because of performance
penalty was simply too high.
So it seems to me that we have got the appropriate mix right here -
RDBMS's have got so sophisticate that they are extremely efficient as far
as tabular data processing goes, and then for queries that are truly complex
and dynamic enough to justify an OO-based approach, we have the ORM's. |
|
c*****t
发帖数: 1879 | 35 OODB is not technologically superior to RDBMS at all.
1. OODB performance is only suitable for certain types of queries.
Even for the queries OODB actually do better, the gain is relatively
small.
2. Behaviors of OODB can be mimiced using ORM tools, and some features
can be added to RDBMS with a bit effort without dramatic changes.
Examples: OID, composite type, type/table inheritance etc.
3. OODB still does not solve the more critical problems of RDBMS,
like schema issues, types |
|
F****n
发帖数: 3271 | 36 I found it would be too expensive to discuss all those questions:))
But as to the performance issue, the key thing is, all relational operations can be implemented with same or better performance in OODB with proper storage / indexing strategy. In other words, conceptually RDBMS can be regarded as a special case of OODB. Downgrading an OODB to RDBMS is very easy, but upgrading a RDBMS to OODB would be difficult, requiring ugly patching such as ORM. That's why 10 years ago most people in universi |
|
t***e
发帖数: 3601 | 37 Location salt lake city. >1000 employee company.
Sr. Software Developer
Requirements: The ideal candidate must have: - Strong Java SE skills,
preferably through release 1.5. - Solid SQL ability. And possess many of the
following: - Proficiency in Object Oriented design and programming. -
Experience with Object Relational Mapping (ORM), especially Hibernate. -
Experience using web presentation technologies such as JSP, JSF, Ajax, Jamon
, Velocity, or FreeMarker. - Use of web container technologie |
|
t*******e
发帖数: 684 | 38 风马牛
struts I - MVC model 2
spring - AOP, DI
Hibernate - ORM
学学也好，不难学。 |
|
k****u
发帖数: 133 | 39 没用过hibernate，建议你用JPA和annotation，这个应该会成为orm的standard。 |
|
s******e
发帖数: 493 | 40 If you want to get your hand wet with java, you can try the path below.
JCP -> JCWCD, JCBCD (EJB, maybe it is not popular any more. but it is good
for you to understand business layer stuff, especially if you want to learn
orm later), JCWSD -> JCEA
But like any other languages, the paper knowledge will be only good if you
have real time expereince. |
|
k***r
发帖数: 4260 | 41 不想用Hibernate那么复杂的了，越简单越好，DB打算用
H2 database，也是lightweight的，query都很简单，
但是不想直接写SQL了 |
|
|
F****n
发帖数: 3271 | 43 JPA is the standard and it's simple. You can use Hibernate JPA without
learning the Hibernate details. |
|
k***r
发帖数: 4260 | 44 En. Thanks. For my current project, it's a tiny little
one, somehow I feel that hibernate with jpa is a little
heavy. I'll definitely use it for a larger project.
But maybe using hibernate JPA may not be a such bad
idea either, for a small project |
|
g*****g
发帖数: 34805 | 45 tiny little, you may consider object DB. |
|
F****n
发帖数: 3271 | 46 It depends on what do you mean by "tiny little". If you mean memory
footprint, then you probably should write the SQL. If you mean the amount of
code you have to write, then use JPA is a good choice because you will have
the luxury of switching implementations. Moreoever, there are probably
ready-to-use persistent List, Map, and etc in JPA that can save your efforts. |
|
k***r
发帖数: 4260 | 47 I mean a couple of tables and simple relationships.
I'm using an embedded DB (h2) as data source. Just a
simple blog sample type of application, simple CRUD.
Because it's simple, I'm trying to avoid any XMLs,
or other type of configurations, or a whole bunch of
jar files (although jar files is a smaller problem.)
amount of
have
efforts. |
|
F****n
发帖数: 3271 | 48 Then you should write SQL. It is not complicated and will not increase your
dependency size. |
|
o**1
发帖数: 6383 | 49 感觉 JPA/Hibernate 还是把问题搞的太复杂了。
很多应用直接用 jdbcTemplate 就足够了。
或者是 iBatis/myBatis 也很简单实用。 |
|
k***r
发帖数: 4260 | 50 我发那个只有一页文档，貌似比ibatis/mybatis还简单很多，
就是不知道稳定性如何，呵呵 |
|
