j***n
发帖数: 301 | 1 来自主题: BuildingWeb版 - 优化js 一个比较大的算法程序，有20个左右的全局变量，听说全局变量的使用很影响效率。如
果建立一个类似pojo的类，把这些东西都塞进去,然后在函数之间传来传去。理论上能有
多大的改进？ |
|
i****k
发帖数: 804 | 2 In general, use pure Java (POJO) vs. EJB as much as possible.
Architecturally speaking, once you start using EJB, your web services has a
dependency on a specific implementation technology - EJB. This brings a whole
bunch of issues. First, your MTR now includes an EJB container. Second, EJB
itself is a controversial technology. Some published J2EE experts have been
evangelizing J2EE architectures without EJBs, or only stateless session beans.
Third, your collegues will laugh at your design. :-) |
|
c**g
发帖数: 274 | 3 No. Servlet is not POJO (Plain Old Java Object). |
|
f*****g
发帖数: 31 | 4
Sorry I disagree with you again. I know what "modern
object container" you mean. But I think your declairation
of "almost all ... follow this pattern" is inaccurate.
Pre EJB3.0 containers, as not "modern containers", are
not using IoC. Yes they are not modern. But EJB3.0 containers,
shall have many other appoarches. First of all, session
beans will remain normal POJO instantiation mechnism,
no IoC will be used. Entity beans, with annotation definition,
may be or may not be set values with IoC. |
|
L******y
发帖数: 275 | 5 来晚一步！原来这里有那么多Hibernate高手。
一直在做Hibernate MAPPING，不过过去都是去国内的Hibernate论坛看文章。
hibernate可以用来MAP没有PRIMARY KEY的表， 数据库视图也可以用。一般MAPPING有两
种方法，一种是根据OBJECT MODEL生成数据库的TABLE另外一种是根据ERD产生
POJO和XML。我们项目是用stateless session bean加Hibernate。 |
|
r***l
发帖数: 67 | 6 Agree your first part. We should all respect each other here.
About EJB, again please please sperate stateless session bean and entity bean.
Entity bean has been proved to be a failed experiment. No need to argue more
about it.
Stateless session bean is quite handy and perform well. There are so many
succesful larger system running on top of stateless session bean. Also,
stateless session bean does not mean you have to use DTO. You can implement
your business object as POJO, service facacde and |
|
r***l
发帖数: 67 | 7 Technology debate is always not black or white. It is something in between.
You can argue from either way. However, looks like you only see one side of
the story.
Fowler never said that a service layer is unnecessary. Actually in his book,
there's a pattern about the service layer. He claimed once the domain logic is
more complex, a service layer can be used to address the business logic cross
different domain object. True or false?
The answer is true.
Business logic about a specific POJO should |
|
m**c
发帖数: 90 | 8
For MVC framework: try "Struts"
For Presentation Layer: try "Tapestry"
For POJO container: try "Spring" |
|
B******N
发帖数: 445 | 9 等你用ejb3，跟ejb2比较起来你就会appreciate it啦。
你可以完全开发POJO，然后加上annotation，再refactor a little bit。就变成一个
j2ee service啦。no boilerplate code啦。 |
|
o***g
发帖数: 2784 | 10 你们都喜欢怎么写Web Service呢？
POJO? or JSR 181? |
|
g*****g
发帖数: 34805 | 11 Actually I have no idea, I have a spring application,
I expose a bean through XFire, 2 configuration files
and you are done. No changes on code. I guess it's POJO |
|
g*****g
发帖数: 34805 | 12 Can't agree more, and I would pleasantly replace stateless session bean
with Spring managed POJO bean.
object. |
|
s******e
发帖数: 493 | 13 requirements: read only data. Database scheme is a little complicated(maybe
not necessary, but I have no control). several similar products, each have
some subsets. The front looks similar(the data is shown in a table with
different headers) but the results come from different tables.
Technology chosen: jsp/javascript as the front, spring mvc with dao and
ibatis sql map as middle tier.
One thing that i am not quite comfortable with my design is that i tightly
couple url pattern with my POJO logi |
|
m******t
发帖数: 2416 | 14 What kind of "coupling" are we talking about here? The part-of-the-url-is-
the-POJO-method-name kind of coupling would be very bad. |
|
g*****g
发帖数: 34805 | 15 POJO rocks, and I don't think it's slow. |
|
g*****g
发帖数: 34805 | 16 service层面上用POJO是不错的，本身就没有多少重用的问题，
可以group而不是extend。
web framework上，view component很多都是重复的，或者相近的，
比如一整个panel在另一个页面上重复出现是很常见的。无疑hierarchy
很有用。
我不是想争论哪个架构好，我是spring mvc用了很久，觉得这个东西
productivity不够好，JSF看着也一样复杂。觉得wicket的思想不错。
developer
conclusive |
|
g*****g
发帖数: 34805 | 17 web部分是应该很简单，但就因为快不起来，才让我重新考虑这个问题。
常见的比如pagination，比如flow，state在client/server来回转化带来很多麻烦。
包括spring web flow这样的东西，看着不错，其实是把很多if else
扔进了xml，并不符合pojo的思路。JSP EL, JSF EL也是一样的。 |
|
g*****g
发帖数: 34805 | 18 Below are my 2c with limited knowledge on wicket.
IDE can help but definitely will never be as good as POJO. Java is
capable of handling most complex task, why not leave the complexities
there. Toying between js, jsf/jsp, xml and java certainly won't be
productive.
A language is meant to make simple things simple, and difficult things
possible.
Wicket makes it easy to write custom component in pure java, that probably
satisify 90% of common ajax needs, and doesn't stop you from
using your favor |
|
g*****g
发帖数: 34805 | 19 我觉得JSP, JSF，以及相关的tagging library，比如jstl, struts tag lib，
还有基于xml的一些东西，如spring webflow。都把逻辑内建到非java资源里，
这是反POJO的，反MVC的。Java的一大优势就是static typing，因为不同的
需要引入html, xml，比如前者用于web，后者用于configuration，这都可以
理解。但是从程序员的角度讲，并不希望逻辑混入非java资源，这产生了
几个常见问题。
1. Typo，编译器无法静态纠错，往往依赖于测试，比较浪费时间。一旦
逻辑复杂有可能测试不充分。
2. Refactor，重构很难实现，往往依靠于特定工具(如架构的plugin而且功能
有限)而且不可靠
3. view/control混在一块，使得动态和静态页面设计者之间来回增多，并且
使重用困难。而逻辑在纯java代码则使得各种pattern的应用成为可能，比较
容易合理设计达到重用的目的。
我的观点就是，java既然是静态语言，混入这些带入了动态语言的缺点，
而优点则并没有太多体现。我理解我们需要DSL，但我同 |
|
t*******e
发帖数: 684 | 20
你说的JSF的问题没有一个在点上.
JSF到现在已经5年了,占了很大的market share. 所有IDE都支持JSF的开发, debugging
根本不是问题.
除了真正POJO的技术, 重大项目是很难作到完全backward compatible的,Hibernate,
Struts,Tapestry,等等没有例外,特别是触及了low level API的code.
有量化的benchmark说明JSF performance有问题吗? 如果application有performance问
题,十之八九是在Data Access Layer上. Web Layer对performance的影响极小. |
|
g*****g
发帖数: 34805 | 21 spring web flow在我看来也不是什么好东西，大量的逻辑被转到
xml里，
比如这样的一段，用java代码写来就是
if(createItem()){
displayItem();
}
又干净又简洁，在实际项目中，我也从来没有碰到过可以只改flow不改代码
的时候。我认为navigation这种东西，是logic不是configuration，本来就
应该写在java代码里。所以无论struts1/2,spring mvc/flow, jsf等等，就
这但来说本身就是anti POJO的。wicket和echo才是正确的方向。但由于基于
struts，jsf的大量投入，被扭曲了。
，早年使
了Facelets就解
enabled
前有两个BPM支持JSF,
software vendor的角度看，JS |
|
F****n
发帖数: 3271 | 22 对Wicket或类似的FRAMEWORK来说，有一点值得注意，据说Wicket把XUL拿掉了，强调用
POJO的而不是Declarative UI Language. 我觉得这是一大退步。实际上把Declarative
UI和HTML混为一谈是非常可笑的。以前做过大量Swing Programming 的人都知道，用
JAVA做UI是非常MESSY的，Declarative UI（如COCONUT那个）应该是大方向。Wicket这
种把DSL丢掉的做法更象一个MARKET DECISION，短时间内能赢的那些HATE HTML JS的
DEVELOPER（like me)，但时间长了，会发现实际上回到了老路。 |
|
c*m
发帖数: 836 | 23 回国买了本中文翻译的Pojos in Action, 一本Enterprise SOA, 简直看的吐血啊 |
|
g*****g
发帖数: 34805 | 24 You probably want to expose web service from a POJO instead.
Some popular tools are CXF and Axis.
on |
|
b**********g
发帖数: 806 | 25 我们这个东西是这样的,前端一个html的login界面,然后是一个servlet处理request.现
在想把这个做成一个webservices,同时还能把用户名跟密码一起传.这个SOAP
webservices,我从来没用过,所以不知道该怎么开始.从POJO做,是什么意思?多谢了. |
|
g*****g
发帖数: 34805 | 26
This is largely due to that spring does it right first, (IoC, AOP,
POJO oriented, no do one thing with 3 classes), getting mature,
popular and adopted by many open source projects before ejb3 becomes
a spec. ejb3 is pretty much some good practices of spring and
hibernate, and some good features of RoR (convention over configuration),
and I am gonna give it credit for that.
Well, since spring 2.0 and especially after 2.5, you can configure most
spring components using only annotations too. So th |
|
A**o
发帖数: 1550 | 27 define a structure (i.e. a pojo)
it |
|
t*******e
发帖数: 684 | 28 除去license问题，我对不用descriptive language/DSL的UI framework不太认同。用
hierarchical language表达UI要比用imperative language合理。JavaFX也同理。而且
用descriptive language描述UI会让Java code更加POJO。
具体到某个RIA framework，ZK感觉不错。 |
|
t*******e
发帖数: 684 | 29 The nature of Spring Web Flow is continuations and work flow engine. Seam
page flow built on the same concepts can declare page flows through
annotations or programming APIs, XML is not mandatory. Being an XML
hater, one can still enjoy the new web approach without touching XML.
Likewise, it is not difficult to dig into Spring Web Flow native APIs to
manipulate navigations in Java code, while the code will be less POJO.
Since XML has been the only piece you noticed, the nature of the
technology |
|
t*******e
发帖数: 684 | 30 The sample code looks so close to Wicket and Swing. The advantage it claims
is against declarative UI programming, the direction GWT has steered toward.
I wonder how it is going to accommodate the new release of GWT. ZK is still
more advanced in terms of its POJO programming style and declarative UI. |
|
t*******e
发帖数: 684 | 31 用annotation或者XML啊，这样code就比较POJO，详见Spring。 |
|
P*****f
发帖数: 2272 | 32 【 以下文字转载自 Programming 讨论区 】
发信人: Pontiff (树), 信区: Programming
标 题: 现在hibernate这种流行框架
发信站: BBS 未名空间站 (Fri Dec 16 01:15:56 2011, 美东)
是不是都用 annotaion, schemaless的POJO了，
总觉得在表达enity之间关系的时候比schema来得复杂，有没有好的review 文章? |
|
z****e
发帖数: 54598 | 33 spring 3.1非常依赖注释
不过用起来也很方便就是了
基本上我觉得日常能想到的功能，spring都帮着做了
理论上是用了spring+hibernate，其实一直都在用spring
只不过有些lib少了，要去找要去下，还有bug我靠
感觉现在写model比以前简单太多了
以前一个模块又是set又是get的，烦死了，现在都是pojo，简单很多
用注释基本上都搞定了
加上一点点hibernate的东东
其实很快，感觉熟练的话，一个小时一个模块一点问题没有
看了下内存才用了500m不到，确切滴说是464m
还有200m多快300m的富余，作为startup足够了
难点就是网络上的东东太少，spring的document写得很差
就写那一部分，然后这一部分有的时候需要额外的lib，文档中也不说
然后抛出异常之后得去上网搜为什么错，应该早点把maven给弄上去
偷懒了 |
|
r*****s
发帖数: 985 | 34 then if your mysql dba wouldn't conform to db2's schema,
java devs have to develop some kind of mapping -- still
very bad -- maybe mapping first, and then based on unit-
tests, you will start to replace java entities one by one,
without affecting the impl above.
permanently
has
too |
|
t*******e
发帖数: 684 | 35 侧重不同罢了. 我是比较喜欢POJO的, API尽量不用, 用到了再查不难. 如何有效的使
用技术是设计的前提. 这个恰恰是书本的强项. 只要运用对头, 编程有些差别也是殊途
同归. 前些天有个帖子说编程就是武侠, "看山是山,看水是水.看山不是山,看水不是水
,看山还是山,看水还是水", 就有点这个意思.
改, |
|
z****e
发帖数: 54598 | 36 可以去，除了m以外
其它三个都有招core java的人
前一段jobhunting不是还有人在说这事么？
说他在找core java的职位，然后面的就是这几家
不过core java跟j2ee多少有些不是一回事
你要注意这两者的区别
尤其是j2ee web这一块的
web这一块变动太大了
包括客户端的东西，几天一变
建议多关注一下service tier或者说business tier
也就是容器这一块，spring和ejb是这一层仅有的两个选择
两个都搞定也没什么大不了的，spring的概念比较超前，ejb比较传统
然后是orm这一层，注意这一层也有ejb，entity bean，不过已经deprecated鸟
现在orm全部都是pojo，这一层主要还是hibernate
不过ibatis等也都有人用，主要idea知道就是了
这一层还有web层的东西的核心思想都是一致的
掌握其中一个很容易可以理解其它框架的思路，不算太难
唯一有着巨大区别的就是spring和ejb，这一层这两个东西整个理念都不一样
ejb通过传统的jndi调用，spring则是ioc，但是这两者又不冲突
必要时候可... 阅读全帖 |
|
s******e
发帖数: 493 | 37 ejb 1.0 was pain in ass to use. That was part of reason rod johnson wrote
his famous book "... development without ejb" sorry forgot the exact book
name. it was also part of reason Gavin king started the hibernate and Rod
john start spring. To provide a lightweight entity mapping DB entity, and a
lightweight business container to practice "code to interface and
dependency injection" which actually originally eyed on session bean and
message bean. Spring eventually evolve to sth like a god frame... 阅读全帖 |
|
z****e
发帖数: 54598 | 38 可以去，除了m以外
其它三个都有招core java的人
前一段jobhunting不是还有人在说这事么？
说他在找core java的职位，然后面的就是这几家
不过core java跟j2ee多少有些不是一回事
你要注意这两者的区别
尤其是j2ee web这一块的
web这一块变动太大了
包括客户端的东西，几天一变
建议多关注一下service tier或者说business tier
也就是容器这一块，spring和ejb是这一层仅有的两个选择
两个都搞定也没什么大不了的，spring的概念比较超前，ejb比较传统
然后是orm这一层，注意这一层也有ejb，entity bean，不过已经deprecated鸟
现在orm全部都是pojo，这一层主要还是hibernate
不过ibatis等也都有人用，主要idea知道就是了
这一层还有web层的东西的核心思想都是一致的
掌握其中一个很容易可以理解其它框架的思路，不算太难
唯一有着巨大区别的就是spring和ejb，这一层这两个东西整个理念都不一样
ejb通过传统的jndi调用，spring则是ioc，但是这两者又不冲突
必要时候可... 阅读全帖 |
|
s******e
发帖数: 493 | 39 ejb 1.0 was pain in ass to use. That was part of reason rod johnson wrote
his famous book "... development without ejb" sorry forgot the exact book
name. it was also part of reason Gavin king started the hibernate and Rod
john start spring. To provide a lightweight entity mapping DB entity, and a
lightweight business container to practice "code to interface and
dependency injection" which actually originally eyed on session bean and
message bean. Spring eventually evolve to sth like a god frame... 阅读全帖 |
|
e*****t
发帖数: 1005 | 40 Pojo就是个提法\concept，不能literally的理解。 |
|
t*******e
发帖数: 684 | 41 相对而言，springsource私有化了，就有了vendor lock-in的可能性。不过大部分
spring beans可以做到真正POJO，只要不用spring annotations而用JSR-250 common
annotations. |
|
z*******3
发帖数: 13709 | 42 那个offer已经不重要了
关键是很多人还是不懂为什么要搞j2ee
这才是真正有趣的部分，offer本身没有意义
回到当初pojo的讨论
为什么会有spring这种东西存在？
因为spring不要求用户继承任何的class或者是interface
所以spring超火爆，丫太爽了，这个东西居然不要求我继承这个继承那个
跟当初煞笔的ejb不一样，什么都要我去继承
继承的越多，各种条条框框就越多
写起来就束手束脚的，最后都不知道在写什么
改一个还怕把别人的东西给弄错了
abstract这个关键字存在有其历史原因
但是随着时间的发展，人们在用其他东西来替换这个东西
使得整个结构更加简洁明了，依赖更低
不是我不懂过去，是有些人看不到将来 |
|
z****e
发帖数: 54598 | 43 今天我吃饭时候想了想
为什么我这么长时间不用abstract class了？
而这个概念是如此的简单，当初学java时候就学过了
但是工作中为什么都没用到呢？这个想法倒是很有趣
然后我看了一下你的这个实例，我大概明白为什么了
首先先从你这段开始
你这一段一个类，目测过去，做了不少事情
又是configuration，又是handler，又是constants的
我们先看看大师的代码是怎么写的，看hibernate
hibernate对于configuration有专门的configuration类
然后对于handler，我假设这是一个sessionfactory一样的东西
然后对于你的CRUD，我假设有一个类似session一样的东西
来看hibernate是怎么写的
Sessionfactory sessionfactory = Configuration.buildSessionfactory();
//第一层，从config到factory
Session session = sessionfactory.openSession();
//第二层，从factory到produc... 阅读全帖 |
|
c*****e
发帖数: 3226 | 44 用OpenGSE 很灵活, 感觉除了Hibernate，就是基本上POJO了。测试用用mockito.
spring or
Guice for
injection.个人很喜欢Guava. akka |
|
z*******3
发帖数: 13709 | 45 stereotype
heavy的就永远都heavy
ejb3.0以后也都是pojo了
要是websphere没有人用了
ibm的市值怎么爬上200b的？ |
|
a*******m
发帖数: 626 | 46 +1
ejb3向spring学了很多。
stereotype
heavy的就永远都heavy
ejb3.0以后也都是pojo了
要是websphere没有人用了
ibm的市值怎么爬上200b的？ |
|
k********e
发帖数: 368 | 47 搞技术的人就容易极端。其实很简单的问题搞得太复杂。
萝卜白菜，各有所爱。大家在纠结什么app server好，人家已经用dot net搞起新系统
了。so what？
小公司为了省钱，用开源的，因为系统小，用tomcat。 好选择
中型公司，有了些钱和数据，为了应付增加的流量和安全性能，开始用jboss。好
大型公司为了确保稳定和系统的连贯，维护，继续使用weblogic， websphere。他们不
在乎几十万的费用。你让他们改架构，就是找扁。好
google，amazon等巨型公司，市场上根本没有他们能用的系统，他们就自己开发。好
ejb还是spring？ 新项目当然用spring，也有的公司用ejb3，因为ejb3和spring的差距
不大了，而且是标准。 老项目继续ejb，不重要的老项目有钱有人的时候可以改成
spring。
至于有人说为什么JEE不JBOSS，答案就是JBOSS就是JEE certified。
JTA也是JEE标准。 这些搞不清的话，需要搞清楚在讨论，省得浪费时间，误导观众。
EJB的好处是在10年以前。现在基本就是POJO了。 EJB3继续大行其道是因为他学... 阅读全帖 |
|
z*******3
发帖数: 13709 | 48 我估计也是
这种legacy code
要想一下子理解，不是那么容易
毕竟不规范
你这种问题问一下其他老员工
也就是一分钟的事
远比你自己在这里问然后找要容易得多
j2ee就是这样，层与层之间的关联
没有你想得那么容易
往往这些关联是用框架来实现
也就是你光看代码，你是找不到的
你得去看配置文件，所以就很不直观
所以这就是为什么我长期强调规范代码
因为规范的代码查起来有官方文档的帮忙
不规范的代码，除了公司自己的人知道，就没有人知道了
不过你这个还好，图画出来我大概明白了
层次是这样
jsp->servlet(封装pojo，也就是实体，set/get方法)->ejb->bo?->*dao(这里应该是用
上了虚拟类的继承)->db
够原始的系统，ejb1.x版本时候的事，struts什么都没用上
好处是对你基础的提高很有帮助
你断掉的那个逻辑是在servlet到ejb之间
看ejb的配置文件，还有就是这个servlet应该有一个总的dispatcher
就是总的派发servlet的类，找找这个类，大概读一读代码
也许能够领悟，不过这非常不容易，我一般遇到这种就直接问了
问同事会快很多，没... 阅读全帖 |
|
z*******3
发帖数: 13709 | 49 是的，如果你只是做web的话
可能就只有这么简单
所以web上用php可能会更方便
因为涉及不到太复杂的东西
如果只是增删改查这些跟db完全匹配的操作
一般都只要3－5行就搞定
但是如果要涉及到复杂的商业应用
比如保险的保费计算，那这么大一个东西
放在servlet里面就不合适了，servlet很快就会膨胀到你无法忍受的地步
尤其是要在servlet之间互相调用的话，旧系统一个类几千几万行代码就这么发展起来的
把代码拿出来放到另外一个类里面去也是这些东西发展起来的第一步
还有就是pojo如果不管理的话，bean一多，内存的消耗会吃不消
尤其是如果新建一个对象需要涉及io操作的时候，就很慢
而自己去写，写得不好会内存泄漏，也麻烦
spring里面对于这些可以复用的bean全部缺省设置为singleton
这都是大系统而言，小系统无所谓，想怎么写都行 |
|
