|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-09-14
发言， 有心得分享， 赞同，欢呼， 膨胀，话语霸权， 反省批评，谦逊。 循环往复。
可类比： 需求， 设计， 开发，编码， 测试， bug find, refactor, bug fix, 。 迭代开发。 只要这个循环能正常运行就好 。 :-) |
| 返回顶楼 | |
|
发表时间：2004-09-14
potian 写道 我相信dlee的气度，你多虑了，呵呵
何况robbin对事不对人的 这个问题我想我也存在的 我说的所有观点都只代表我个人。都是我自己从事这么多年基层软件开发工作的一些真实想法。即使这些观点是完全错误的，我也可以承担其所造成的后果。 |
| 返回顶楼 | |
|
发表时间：2004-09-15
我没有ejb的实际经验，也没有hibernate的实际经验。
所以本来不该插话。 不过，我觉得，robbin是不是应该考虑淡化这个论坛的hibernate味道。 这不是一个hibernate论坛，而是一个java技术论坛。 那么，各种java技术至少都应该有一席之地。 不要形成hibernate打压ejb，轻量级打压重量级的气氛，那样，和jdon不是也差不多了？ 如果你开一个ejb版，把这里的气氛弄得对ejb友好些，只怕jdon那里就真的要倒闭了。 |
| 返回顶楼 | |
|
发表时间：2004-09-15
ajoo 写道 我没有ejb的实际经验，也没有hibernate的实际经验。
所以本来不该插话。 不过，我觉得，robbin是不是应该考虑淡化这个论坛的hibernate味道。 这不是一个hibernate论坛，而是一个java技术论坛。 那么，各种java技术至少都应该有一席之地。 不要形成hibernate打压ejb，轻量级打压重量级的气氛，那样，和jdon不是也差不多了？ 如果你开一个ejb版，把这里的气氛弄得对ejb友好些，只怕jdon那里就真的要倒闭了。 不是没有想过。但是问题是我们都比较一致的反对EJB2，恐怕这个版没有办法得到健康的发展。而EJB3还是draft，似乎讨论的话早了一点点。也许可以考虑开一个EJB3和JDO2版，但要前看看大家的意见。 |
| 返回顶楼 | |
|
发表时间：2004-09-15
也不是所有人都反对吧？jini, flyisland不都可以挑一下大梁吗？
什么技术都不是完美的，你hibernate就没毛病？spring就没毛病？ 记得你说，这里是以实际项目开发为核心，而不是单纯关心纯技术，纯理论的优劣，对么？ ejb2在实际工作中应该还是有一定用途的吧？（就算它是历史原因也好） 有应用，就会有讨论，大家就可能需要交流经验。 反对ejb的大可在深度区里面形而上，但是你们的反对不可能否定ejb仍然在项目开发中占一定比例这个事实。 就象我反对容器要求我公开构造函数，但是事实上容器就这么规定了，我也无法否定这个事实，对么？ |
| 返回顶楼 | |
|
发表时间：2004-09-15
spring嘟嘟 写道 先要搞清楚企业应用的核心问题是什么？
EJB到底是用来做什么的？在什么场合下用的？没有什么是可以放之四海皆准的真理。 让我们来试想这么一个场景，杭州市政府要做一个一体化的领导辅助决策系统（不仅仅是数据分析这么简单，要求对数据流程上的一个控制）来提高市政府的决策能力，这个项目假如是包给我来做的，那我怎么办？难道要我去熟悉每个部门的业务流程？OK，如果现在市面上已经有存在各个部门的中间件（这里我假定用EJB来实现），他们各自对每一个部门/行业都有多年研究的，对于业务的理解肯定要比我更深入，而且安全性，准确性更高。我现在要做的其实就是把各个中间件采购来，进行组合，做出统一的用户界面来就OK了。 这样做是对客户的负责，有人可能要说这样我的钱会少赚很多，会吗？不会的，对于小型项目的维护费用可能很小，但是对于大型项目的维护成本可能要比开发费用更费，而且在限定的期限内做大型项目的时候，能否招到这么多合适的员工，保持团队的沟通，保证团队的稳定性都是一个不小的成本。 对于小型项目我喜欢用一些轻量级的解决方案，而且对于在市场上可以买到的产品我会先用他们的产品，如果这个产品很有市场，我多研究几个，从而自己开发这么一个产品来。 举个例子吧：我前面有一个项目是45W，采购别人的系统花了8W，用3个人2个月也就是6个人月实施，对外的人员费用是1.2W/M，当然内部费用更低，这样除去先前一些开销和项目完结之后的开销，这个项目赚了23W。假如这个系统完全自己开发可能需要5个人4个月，也就是20个人月，且客户不一定象现在这么满意，里面赚多赚少自己算吧！而且需要自己维护的东西比原先要少了。 其实一个软件企业没有后台资金强力支持的话，要把企业做大，就先做一些软件实施来养活自己，而把好的开发人员用于去做技术积累。 以上为一家之言，接受大家的砖头:):):) 这个是业务组件的积累，我不认为EJB和不EJB有什么区别，相反在集成第三方系统或者扩展这个环节上,EJB是弱势的 最好大家做成EJB也好用，非EJB也好用，我可以根据项目选择不同的构架 |
| 返回顶楼 | |
|
发表时间：2004-09-15
据个具体的例子吧，gigix它们公司有一个产品是统一用户管理(提供一个组织机构/授权模型加上一个单点登陆机制），他们提供一个hessian的远程接口
现在有两个不同公司的两个不同应用，我都在负责。 其中一个对用户的需求比较简单，直接用remotefacade使用它们的用户模型和单点登陆就可以了，所以我很方便地用起来了。 但另一个项目不但要使用他们的单点登陆功能，还希望使用他们内部的组织机构管理，因为那个项目的模型非常复杂，所以我希望进一步扩展这个模型，直接嵌入到这个项目的代码中去。 |
| 返回顶楼 | |
|
发表时间：2004-09-15
我是希望组件的实现能够重用的范围越广越好，讲句老实话，你用非EJB实现的组件，我套一层sessionfacade是很简单的事情，甚至可以用一段脚本自动来生成那些接口，我全部符合你的规范
|
| 返回顶楼 | |
|
发表时间：2004-09-15
我还是很怀疑到底有多少组件是可以及取及用的，不需要扩展的，至少我很少用到过
引用 整个2008奥运系统，市场上有好多模块，用EJB实现所有模块，也有不用EJB实现的模块，但是各自框架不同，如果你是决策者，你会怎么选择，自己开发所有？选择EJB？选择不同框架下的非EJB实现？ 如果这些组件都没有侵入性，我就好办了 |
| 返回顶楼 | |
|
发表时间：2004-09-15
EJB当然是有用的，也有很多资产，EJB想要做到的事情都是非常有价值的，有他们适合的场景，这是谁都承认的。
但是EJB能做到的事情其他手段也能做到，以前是EJB独家提供一体化解决方案，现在有很多方式，譬如EJB3.0的发展方向和JBOSS的AOP方案，他们的目标就是降低侵入性，提供可拆卸的服务，这个事情大家都要看明白，这是一个大势。 |
| 返回顶楼 | |
