<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
  <channel>
    <title>pig345</title>
    <description></description>
    <link>http://pig345.javaeye.com</link>
    <language>UTF-8</language>
    <copyright>Copyright 2003-2008, JavaEye.com</copyright>
    <docs>http://blogs.law.harvard.edu/tech/rss</docs>
    <generator>JavaEye - 做最棒的软件开发交流社区</generator>
      <item>
        <title>有感而发：JavaEE和ROR的本质区别，以及对ROR的抱怨</title>
        <author>pig345</author>
        <description>
          <![CDATA[
          <br/>
          作者: <a href="http://pig345.javaeye.com">pig345</a>&nbsp;
          链接：<a href="http://pig345.javaeye.com/blog/199384" style="color:red;">http://pig345.javaeye.com/blog/199384</a>&nbsp;
          发表时间: 2008年06月02日
          <br/><br/>
          声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！
          <br/><br/>
          <p>粗算下来，作java开发也有6、7年了，期间也短暂搞过其他技术（vb、.net、office），但还总体上是以java为主不断坚持着。。。<br />
<br />
直到07年被《程序员》杂志和javaeye&ldquo;忽悠&rdquo;，到ROR的世界游历了一番（做了1.5个项目），今天刚好碰到这篇博客http://morris.javaeye.com/blog/198982，<br />
有感而发，说点自己的看法：<br />
<br />
从架构思想上看：<br />
<br />
JavaEE的（起码早期的）思想一直是 用大型架构 建设 错综复杂的商业系统（注意这些系统中web只是所用的众多技术中的一部分），导致他十分强调分层，开发部署比较繁重。<br />
这个思想根深蒂固，几乎影响了所有java框架的设计。甚至所谓的轻量级框架也是如此。<br />
（似乎成了企业级技术的特点，看看现在火热的SOA，其复杂和繁重程度甚至比JavaEE更严重）。<br />
<br />
ROR显然没这么大的野心，它要解决的只是如何快速搭建好一个网站（因此会更注重如何多多利用web标准：html、css、javascript），他在架构上的考虑就只是MVC，能保持一个好的程序结构即可，根本无须分层。<br />
（与JavaEE这么多年一直拥抱SOA对比，ROR到了2.0更是抛弃了webservice，转到更加简洁的REST了）<br />
<br />
但是sun没想到实际中大多数人开发的东西没那么复杂，反倒更强调快速开发、快速适应变化，因此ROR在java社区里面引起很大反思。<br />
（在中国这个情况更加普遍，系统不复杂、倒是需求变化快。。。）<br />
（在网站制作领域一直都是喜欢用脚本语言，可以做到快速编码、快速部署、快速变化。PHP就是一个例子，只不过PHP结构实在太差，java们一直看不上眼，而ROR实现的MVC却相当正统、严密，框架结构甚至比流行的java框架如ssh作的更完美，这自然引起了java们的广泛兴趣）<br />
<br />
看起来，ROR就像一枚银弹，尤其是对咱们这些中国的开发人员<br />
然而实际作起来，你会发现：<br />
1）从语言环境到应用框架都不熟悉，需要不短的一段时间学习和准备<br />
（对于那些看了几天 文档／视频／教程 就敢轮胳膊开干，还说入门简单学习曲线低的，我真要骂人了：不是人您就别在人堆里面瞎炫耀了）<br />
2）动态语言真的很动态，没有编译过程，你可能会犯下一些低级错误，而具体到Rails框架中，因为使用了各种动态的代码生成技术，导致要想搞清楚其中一些bug，可能需要你花费几个小时进行跟踪查找。<br />
3）Rails中的View是基于html的模板技术，这跟jsp类似，你需要自己控制自己，因为没人会阻止你在里面写业务代码。<br />
4）ruby之前应用的还比较少，一些常见解决方案还非常不完善（比如：全文检索，目前最好的ferret，还是有bug经常导致rails意外退出）。<br />
5）Rails的各种插件比较多，但是质量不齐，有些看起来很cool，但是无法深入定制（比如：ROR书里面提到的streamlined，就有点像玩具），具体的调研和选择代价比较大。<br />
6）有时碰到Rails插件的bug或功能缺陷，如果你自己直接改的话，之后的插件升级版本管理上似乎会有点麻烦，需要你手工合并。<br />
7）可能你要自己解决部署后的源代码保护问题，而这个问题对于产品开发无疑是最重要的。<br />
8）动态语言的全面掌握需要比静态语言花费更多时间精力。<br />
<br />
呵呵，泼了这么多凉水，其实是想说明一点：要认真地对待ROR技术，不要被一些宣传所蒙蔽。<br />
基本上，在没有熟练掌握ROR、而又需要深入开发的时候，ROR带来的好处（代码量少、开发修改部署快），和他带来的各种问题几乎可以互相抵消，千万别以为能省多少时间。<br />
但是从长远看，代码量少还是非常吸引人的，想象一下，同样的业务逻辑代码，10万行和100万行那个更容易维护？<br />
<br />
偶然和一个作过ROR的开发人员有过一次交流，发现大家目前的想法有点相似，ROR更适合少量的高手合作开发，或者私人接活。<br />
普通的团队开发似乎还需要大量探索。</p>
          <br/>
          <span style="color:red;">
            <a href="http://pig345.javaeye.com/blog/199384#comments" style="color:red;">本文的讨论也很精彩，浏览讨论>></a>
          </span>
          <br/><br/><br/>
          <span style="color:#E28822;">JavaEye推荐</span>
          <br/>
          <ul class='adverts'><li><a href='/adverts/42' target='_blank'><span style="color:red;font-weight:bold;">搜狐网站诚聘Java、PHP和C++工程师</span></a></li><li><a href='/adverts/41' target='_blank'><span style="color:red;font-weight:bold;">北京: 千橡集团暨校内网诚聘软件研发工程师</span></a></li></ul>
          <br/><br/><br/>
          ]]>
        </description>
        <pubDate>Mon, 02 Jun 2008 12:37:38 +0800</pubDate>
        <link>http://pig345.javaeye.com/blog/199384</link>
        <guid>http://pig345.javaeye.com/blog/199384</guid>
      </item>
      <item>
        <title>RichDomainObject的架构设计中，是否可以抛弃DAO？</title>
        <author>pig345</author>
        <description>
          <![CDATA[
          <br/>
          作者: <a href="http://pig345.javaeye.com">pig345</a>&nbsp;
          链接：<a href="http://pig345.javaeye.com/blog/79822" style="color:red;">http://pig345.javaeye.com/blog/79822</a>&nbsp;
          发表时间: 2007年05月14日
          <br/><br/>
          声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！
          <br/><br/>
          2、3年过去了，没想到最近Javaeye又有了对Domain设计的热贴，安耐不住，说说自己的想法。<br /><br />2年前有过尝试RichDomainObject的设计，当时使用的hibernate2＋SessionBean。<br /><br /><strong>发现DomainObject必须要依赖Dao</strong>（一些业务逻辑执行前，需要对之前产生的DomainObject进行查询或汇总，根据结果判定执行逻辑）；<br /><strong>同时为了查询的灵活，Service必须同时依赖Dao和DomainObject</strong>。<br /><br />这样整个Server，实际上包括了4种东西：<br />Service、<br />ServiceDAO（ReadOnly）、<br />DomainObject、<br />DomainDAO(Read/Write)。<br /><br />另外在Service层和各种Client端（Web/Swing/JavaApplication等）之间使用DTO传递数据。<br />注意DTO并不是与DomainObject一一对应的的PO无逻辑简化版本，相反DTO是与界面相关的，同一个DomainObject可能根据客户端（界面）的不同，有多个DTO与之对应。（演化到后来DTO变为了由集合、数组、String、Date、Integer等java基础类组合的一个数据结构，系统本身并不存在具体的DTO类，因为数据到界面后只为显示，并没有任何逻辑，无须用对象实现）。<br /><br /><strong>这样的架构下，感觉DAO的处理上实在是繁琐的很，时时有绕过它直接使用hibernate的冲动！</strong><br /><br />技术在不断进化，JPA的出世，让我看到了一丝希望。<br /><br />反思一下DAO出现的原始用意：<br />1）隔离数据库（JDBC）操作。［分层、弱化程序对数据库的直接依赖］<br />2）简化数据库间移植。［隔离具体数据库接口（SQL）细节，解除厂家邦定］<br /><br />目前的JPA似乎完全满足了上面两种需求。<br /><br />而且（JPA）是JAVA持久化API，不是JAVA数据库连接API（JDBC），其从概念上也是不依赖数据库的（完全有可能实现一个使用文件系统／XML进行持久化的JPA）。<br />同时，JPA本身也是一个隔离层，虽然目前作的不太完美，不过仍然给了你一个可以切换各种不同的JPA实现的机会。<br /><br />现在看来我们是否可以抛弃DAO了呢？<br />让代码直接依赖java的标准api－－JPA，就像依赖java.util一样？
          <br/>
          <span style="color:red;">
            <a href="http://pig345.javaeye.com/blog/79822#comments" style="color:red;">本文的讨论也很精彩，浏览讨论>></a>
          </span>
          <br/><br/><br/>
          <span style="color:#E28822;">JavaEye推荐</span>
          <br/>
          <ul class='adverts'><li><a href='/adverts/42' target='_blank'><span style="color:red;font-weight:bold;">搜狐网站诚聘Java、PHP和C++工程师</span></a></li><li><a href='/adverts/41' target='_blank'><span style="color:red;font-weight:bold;">北京: 千橡集团暨校内网诚聘软件研发工程师</span></a></li></ul>
          <br/><br/><br/>
          ]]>
        </description>
        <pubDate>Mon, 14 May 2007 14:40:57 +0800</pubDate>
        <link>http://pig345.javaeye.com/blog/79822</link>
        <guid>http://pig345.javaeye.com/blog/79822</guid>
      </item>
  </channel>
</rss>