阅读:154081次
评论:103条
更新时间:2011-06-01
工欲善其事,必先利其器。在我们深入Struts2之前,我还是想废一些口舌来讲述一下开发环境的搭建。每个人都会根据自己的习惯来搭建自己的开发环境。开发环境是否便捷,也将直接影响开发的效率。所以对于开发环境已经非常熟悉的朋友可以直接忽略这篇文章。而我在这里给大家介绍一下我的开发和调试环境的搭建,之后所有的章节的代码,也都将建立在这个开发环境之上。
在编写J2EE程序的时候,我们往往需要一个Web容器进行调试,比较常见的Web容器是Tomcat,在Eclipse等IDE中,也有很多针对Tomcat的插件支持,使你可以很轻松地在Tomcat上调试你的J2EE应用。而我所使用的Web容器是更加轻量级的Jetty。利用它进行J2EE的开发和调试,甚至只需要依赖Jetty的jar包即可。
在编写J2EE程序的时候,我们往往需要一个Web容器进行调试,比较常见的Web容器是Tomcat,在Eclipse等IDE中,也有很多针对Tomcat的插件支持,使你可以很轻松地在Tomcat上调试你的J2EE应用。而我所使用的Web容器是更加轻量级的Jetty。利用它进行J2EE的开发和调试,甚至只需要依赖Jetty的jar包即可。
搭建最简单的开发环境
首先我们来看看如何搭建最简单的J2EE项目的开发环境。
1. 我们需要建立的一个空的J2EE项目的目录结构
在这里,我简单解释一下这些目录的作用:
src(source folder):存放所有的Java源代码。
conf(source folder):存放所有的配置文件。
test(source folder):存放所有的Java测试代码和调试代码。
web:web项目的根目录,下面有WEB-INF目录以及在此之下的classes和lib目录。classes目录将会成为所有的source folder的编译对象目录,而lib目录则存放项目所依赖的jar包。
lib:也存放jar包,这些jar包可能仅仅在开发调试时依赖,项目本身则不依赖这些jar文件。
2. 编写IDE相关的文件
在这里,你还能看到classpath文件和project文件。这两个文件是导入到eclipse中所必须的文件,是我为eclipse工程而写的文件。如果你使用其他IDE,可能需要自行编辑与其他IDE相关的项目文件。
在建立了这些目录结构后,你就可以将其导入到eclipse中作为eclipse的工程了。
3. 加入相关调试所需要的jar包,并指定classpath
接下来,我们把Jetty所需要的jar包copy到lib目录下,并在IDE中指定classpath。
4. 添加Jetty启动类
在test下建一个runtime的目录,并添加Jetty启动类。
如果此时,你在WEB-INF下有web.xml,那么你就可以执行上面这个Jetty的启动类。
5. 启动、调试、测试
执行了Jetty的启动类后,可以看到启动界面的日志:
这表示你已经成功启动了Jetty作为你的Web服务器。当然,你可以使用Debug模式来执行Jetty类,这样就进入了调试模式,你可以在代码中设置断点进行调试。
在这里,还有一点需要简单提一下,默认情况下,Jetty会在windows上使用缓存,所以会把js,css等文件进行锁定,使你无法编辑。为了解决这个问题,需要设置一些默认参数。这里,我们可以使用google大法,已经有朋友为我们解决了这个问题:
http://www.blogjava.net/alwayscy/archive/2007/05/27/120305.html
所以,我在runtime的同级目录建立了一个webdefault.xml文件,并且指定Jetty使用该文件作为默认的参数设定。
【小结】
在上面我介绍了我个人的开发调试环境,这种开发环境的好处可能有一下这些:
1. 开发环境不依赖于任何IDE或者相关的插件,只需要运行Java文件即可进行调试。(当然,你可能需要编写IDE相关的project文件来获取IDE的工程支持)
2. 开发环境不依赖于任何外部的Web服务器,与环境无关,所以无论将项目迁移到哪里,都可以直接运行。
3. 不需要开发人员额外学习如何搭建开发环境,开发环境已经内置,降低了开发人员的学习成本。
1. 我们需要建立的一个空的J2EE项目的目录结构
在这里,我简单解释一下这些目录的作用:
src(source folder):存放所有的Java源代码。
conf(source folder):存放所有的配置文件。
test(source folder):存放所有的Java测试代码和调试代码。
web:web项目的根目录,下面有WEB-INF目录以及在此之下的classes和lib目录。classes目录将会成为所有的source folder的编译对象目录,而lib目录则存放项目所依赖的jar包。
lib:也存放jar包,这些jar包可能仅仅在开发调试时依赖,项目本身则不依赖这些jar文件。
2. 编写IDE相关的文件
在这里,你还能看到classpath文件和project文件。这两个文件是导入到eclipse中所必须的文件,是我为eclipse工程而写的文件。如果你使用其他IDE,可能需要自行编辑与其他IDE相关的项目文件。
在建立了这些目录结构后,你就可以将其导入到eclipse中作为eclipse的工程了。
3. 加入相关调试所需要的jar包,并指定classpath
接下来,我们把Jetty所需要的jar包copy到lib目录下,并在IDE中指定classpath。
4. 添加Jetty启动类
在test下建一个runtime的目录,并添加Jetty启动类。
package runtime; import org.mortbay.jetty.Connector; import org.mortbay.jetty.Server; import org.mortbay.jetty.nio.SelectChannelConnector; import org.mortbay.jetty.webapp.WebAppContext; /** * Jetty Server starter. Use embedded mode. * * @author Downpour */ public class JettyStarter { /** * @param args * @throws Exception */ public static void main(String[] args) throws Exception { long begin = System.currentTimeMillis(); Connector connector = new SelectChannelConnector(); connector.setPort(Integer.getInteger("jetty.port", 8080).intValue()); WebAppContext webapp = new WebAppContext("web", "/struts-sample"); webapp.setDefaultsDescriptor("./test/runtime/webdefault.xml"); Server server = new Server(); server.setConnectors(new Connector[] { connector }); server.setHandler(webapp); server.start(); System.out.println("Jetty Server started, use " + (System.currentTimeMillis() - begin) + " ms"); } }
如果此时,你在WEB-INF下有web.xml,那么你就可以执行上面这个Jetty的启动类。
5. 启动、调试、测试
执行了Jetty的启动类后,可以看到启动界面的日志:
15 [main] INFO org.mortbay.log - Logging to org.slf4j.impl.SimpleLogger(org.mortbay.log) via org.mortbay.log.Slf4jLog 15 [main] INFO org.mortbay.log - jetty-6.1.7 1109 [main] INFO org.mortbay.log - Started SelectChannelConnector@0.0.0.0:8080 Jetty Server started, use 1547 ms
这表示你已经成功启动了Jetty作为你的Web服务器。当然,你可以使用Debug模式来执行Jetty类,这样就进入了调试模式,你可以在代码中设置断点进行调试。
在这里,还有一点需要简单提一下,默认情况下,Jetty会在windows上使用缓存,所以会把js,css等文件进行锁定,使你无法编辑。为了解决这个问题,需要设置一些默认参数。这里,我们可以使用google大法,已经有朋友为我们解决了这个问题:
http://www.blogjava.net/alwayscy/archive/2007/05/27/120305.html
所以,我在runtime的同级目录建立了一个webdefault.xml文件,并且指定Jetty使用该文件作为默认的参数设定。
【小结】
在上面我介绍了我个人的开发调试环境,这种开发环境的好处可能有一下这些:
1. 开发环境不依赖于任何IDE或者相关的插件,只需要运行Java文件即可进行调试。(当然,你可能需要编写IDE相关的project文件来获取IDE的工程支持)
2. 开发环境不依赖于任何外部的Web服务器,与环境无关,所以无论将项目迁移到哪里,都可以直接运行。
3. 不需要开发人员额外学习如何搭建开发环境,开发环境已经内置,降低了开发人员的学习成本。
完善Library的管理方式
在上面搭建环境的过程中,我们发现,Library的管理存在着一定问题。这个问题主要表现为:
1. 不容易做Library的版本管理。如果Library的版本需要升级,那么我们不得不重新copy一份新的jar包,并且借助IDE重新指定项目的classpath。这种劳动,对于一个项目还可以接受,如果你有10多个项目,那么jar包的复制工作会让你很头疼。
2. 每个项目都会有Library的副本。这一点让人非常恼火。实际上,对于一个公司或者一个项目组而言,使用的技术体系基本不变。然而,每个项目的Library却是分开的。不仅如此,每个项目都要从svn中下载大量的相同的Library文件,给我们的硬盘造成极大的空间浪费。对于那些频繁使用Branch的项目来说,这些Library的下载简直就是噩梦。
所以,我们需要一个集中式的Library管理方式。而这一点曾经在Javaeye的海阔天空版激烈得讨论过使用maven来进行管理还是自行管理。
共享类库可以用IDE reference project解决,公司内部项目给常用的lib建立一个project,从CVS上check out,其他工程项目都依赖这个project就可以了,ant build也直接引用这个项目的jar就可以,项目体积照样只有几百K。
——一个讨厌ant,更加讨厌maven的人
我比较赞同Readonly老大的说法而倾向于自行管理。maven这样的高级货,偶实在是用不来啊。那么我们就来看看如何使用共享类库来进行Library管理。
1. 首先建立一个共享类库
建立一个共享类库,将项目中需要共享的Library进行恰当的分类。同时,为每个加入到Library中的jar包进行统一的格式化的命名方式。例如:spring/spring-2.5.5.jar等等。这样的好处在于,一旦jar包的版本有更新,可以加入新的jar包而保留原来的。在项目中,就可以通过引用不同版本的jar包来对Library进行版本管理。
以下就是我个人建立的一个共享类库,大家可以参考:
svn://www.demo2do.com/library
2. checkout共享类库,并将其导入到IDE中作为一个Library工程
3. 为你的项目指定classpath,引用的jar包存在于Library工程中
在这里,我们可以看到,原来项目中的lib目录被删除,jar包也被删除。在项目中所引用的jar包是Library项目中的jar包。
【小结】
完成了上述所有的步骤之后,Library就被集中管理起来,而每个项目也不会再变得那么庞大。当然,开发环境的搭建完全取决于个人的习惯,所以使用各自喜欢的方式吧,不要让环境问题束缚你们的手脚。
1. 不容易做Library的版本管理。如果Library的版本需要升级,那么我们不得不重新copy一份新的jar包,并且借助IDE重新指定项目的classpath。这种劳动,对于一个项目还可以接受,如果你有10多个项目,那么jar包的复制工作会让你很头疼。
2. 每个项目都会有Library的副本。这一点让人非常恼火。实际上,对于一个公司或者一个项目组而言,使用的技术体系基本不变。然而,每个项目的Library却是分开的。不仅如此,每个项目都要从svn中下载大量的相同的Library文件,给我们的硬盘造成极大的空间浪费。对于那些频繁使用Branch的项目来说,这些Library的下载简直就是噩梦。
所以,我们需要一个集中式的Library管理方式。而这一点曾经在Javaeye的海阔天空版激烈得讨论过使用maven来进行管理还是自行管理。
Readonly 写道
共享类库可以用IDE reference project解决,公司内部项目给常用的lib建立一个project,从CVS上check out,其他工程项目都依赖这个project就可以了,ant build也直接引用这个项目的jar就可以,项目体积照样只有几百K。
——一个讨厌ant,更加讨厌maven的人
我比较赞同Readonly老大的说法而倾向于自行管理。maven这样的高级货,偶实在是用不来啊。那么我们就来看看如何使用共享类库来进行Library管理。
1. 首先建立一个共享类库
建立一个共享类库,将项目中需要共享的Library进行恰当的分类。同时,为每个加入到Library中的jar包进行统一的格式化的命名方式。例如:spring/spring-2.5.5.jar等等。这样的好处在于,一旦jar包的版本有更新,可以加入新的jar包而保留原来的。在项目中,就可以通过引用不同版本的jar包来对Library进行版本管理。
以下就是我个人建立的一个共享类库,大家可以参考:
svn://www.demo2do.com/library
2. checkout共享类库,并将其导入到IDE中作为一个Library工程
3. 为你的项目指定classpath,引用的jar包存在于Library工程中
在这里,我们可以看到,原来项目中的lib目录被删除,jar包也被删除。在项目中所引用的jar包是Library项目中的jar包。
【小结】
完成了上述所有的步骤之后,Library就被集中管理起来,而每个项目也不会再变得那么庞大。当然,开发环境的搭建完全取决于个人的习惯,所以使用各自喜欢的方式吧,不要让环境问题束缚你们的手脚。
43 楼 benlsoft 2009-02-04 16:00
42 楼 downpour 2009-02-04 11:49
to downpour :至于人品,我不想和你讨论了,大概看了你写的其它的东西,拿“李刚”作标题。。。太厉害了。我们只谈技术问题,我已经说了你的方式一些问题,看来你是看不明白了,说些你明白的。1.每个项目都需要所有的包吗?难道公司所有项目都是千篇一律。2.显然有些jar运行时是没有必要的,如何区分开发时和运行时的包,如何将项目打一个洁净的包。3.所谓的“完善的lib管理”,说白了就是lib共享,一些常见的IDE都支持shared lib 功能,创建项目时,直接使用就行了,用得着这么麻烦吗?我现在做过的一些项目,其实还没正式采用maven,但一直都有使用ant,作一些自动化的处理(编译,测试,打包,部署),我从来不主张项目构建依赖某一IDE。
看完所有评论的朋友自会对一个人的人品做出评论。我不会把你辱骂别人的话删除,你的人品应该已经昭然若揭了。
关于你的问题,我实在是没有兴趣和你讨论下去了,因为你根本就没有读懂我的文章,所以我也不再和你讨论下去。
41 楼 hantsy 2009-02-04 11:14
至于人品,我不想和你讨论了,大概看了你写的其它的东西,拿“李刚”作标题。。。太厉害了。
我们只谈技术问题,我已经说了你的方式一些问题,看来你是看不明白了,说些你明白的。
1.每个项目都需要所有的包吗?难道公司所有项目都是千篇一律。
2.显然有些jar运行时是没有必要的,如何区分开发时和运行时的包,如何将项目打一个洁净的包。
3.所谓的“完善的lib管理”,说白了就是lib共享,一些常见的IDE都支持shared lib 功能,创建项目时,直接使用就行了,用得着这么麻烦吗?
我现在做过的一些项目,其实还没正式采用maven,但一直都有使用ant,作一些自动化的处理(编译,测试,打包,部署),我从来不主张项目构建依赖某一IDE。
40 楼 downpour 2009-02-03 09:29
39 楼 more000 2009-02-03 00:12
to hantsy:对于你这种从来不仔细看别人的帖子就胡乱发表评论的人而言,我觉得没有必要和你再讨论下去了。你可以继续宣传你的maven和ivy,我依然不能赞同你所有的观点。另外,你对我的文章的不尊重的态度,我也表示对你人格的鄙视。
你写的文章很好,但是,你对别人提出的观点显得很敏感,我觉得没必要吧,我仔细看了hantsy写的,也是有道理的
38 楼 downpour 2009-02-01 20:04
你可以继续宣传你的maven和ivy,我依然不能赞同你所有的观点。另外,你对我的文章的不尊重的态度,我也表示对你人格的鄙视。
37 楼 hantsy 2009-02-01 19:55
hantsy 写道一个简单的问题,你用什么办法保证你所有的lib中的jar文件是兼容的。比如spring依赖的cglib,asm与hibernate依赖的cglib,asm版本不一致,而且众所周知,cglib版本之间兼容性不好。比如(这个只是比方,没有拷证),spring 2.5.4 orm开发时用的是hibernate 3.3.0.GA,你强行引入hibernate 3.3.1.GA,可能引入新的不兼容。显然你没有读懂我的文章。也没有去下载我的svn地址上的library看看我的库到底是怎么样的。费心再给你解释一下。1. 建立一个公共的库,并为这些库进行分类,在每个分类中,可能包含不同的library版本。比如说,cglib中可能会有不同版本的library,我们会把这些版本的library全都放到cglib这个分类中,用不同的文件名进行区分。2. 当你具体做到某个项目的时候,我到底使用哪些jar包是由项目的具体情况而定的。比如说,某个项目,我需要用到Spring2.5.4和Hibernate3.3.0,那么我一定会为这个项目寻找一个同时兼容这2个jar包的cglib,测试通过后,加入到这个具体项目的classpath文件中。3. 不同的项目所引用的jar包是不同的。所以,归根结底只要控制具体项目的classpath文件就能轻松做到jar包的版本管理。所以,没有人会在add了Hibernate 3.3.0GA后,再去add一个Hibernate 3.3.1GA的jar包。这完全是你的误解。
看来你根本就不明白我的意思,这种方法可以说5/6年前都用过,根本就不算什么方法。还是一个最基本的问题,你根本就解决不了版本兼容问题,特别是你这种jar文件随意自选的方式。你说的测试是如何进行的,有没有把的所有依赖的jar文件对应的JUnit Test Case运行起来测试。
我为什么maven在jar版本兼容上优于你的方式,一个很简单的原因,打个比方,一个作者开发一个A jar文件,版本为1.0,它用到了B 1.0,作者发布A jar到maven repository时同时会把依赖关系(A 1.0依赖B 1.0)写到pom.xml文件,同时发布出去。其它开发人员在项目开发时要用A 1.0,只需要把加入到项目依赖中,maven查找依赖时具有传递性,运行时会自动查找A 1.0的依赖(B 1.0),并将它下载到本地,非常精确是B 1.0,是作者开发时使用的版本,不是1.2。
试问,你的处理方式,如果使用Spring 2.5.6,又要使用Hibernate,你是如何知道Spring作者开发时使用Hibernate版本是多少(当然一个简单的方式是下载spring 的with-dependencies包,它自带了各种依赖的合适版本)。
再者冲突问题,前面的提到的cglib,asm在spring,hibernate中版本冲突是的确存在的。这是不管用哪种依赖管理方法都会面临的问题。所有会有SourceLabs的SASH(http://swik.net/SASH,它维护了一些常见的包)通过打补丁的方式彻底解决依赖包之间的冲突问题。在使用maven时,依赖问题尽可能让maven自己去解决,但它也会面临冲突问题,如项目中用到两个包,存在依赖关系A->C 1.0,B->C 1.1,在maven中可以另外单独指定C的版本,如使用最新的1.1,这样做有一定风险,不能保证A在运行时不问题,这样有一点武断。但是你的方法,每个第三方jar加入都是武断的。
ivy能够比较雅的解决冲突问题,处理方式比maven更细,这个我还没有仔细研究过。目前,SpringSource官方的产品,IBM的projectzero都是用ivy维护其repository。最新的 ivy 2.0支持直接使用maven 2的repository。
36 楼 hantsy 2009-02-01 19:17
realghost819 写道你这篇文章的功能maven都有啊有依赖关系的类库你怎么解决?maven的继承功能你这种方法也无法实现。maven怎么用不来?你们讨论的帖子在那里,看看学习下我最大的问题在于,maven是如何解决library的副本问题的?就是说,如果我某个项目,开很多个branch,是不是每个branch依然需要下载那么多的lib包?依赖关系?一个项目起来的时候,难道项目经理的经验还不足以确定类库的依赖关系嘛?
看来,你是根本就没有用过maven,ivy之类的依赖管理工具。
项目版本控制一般只需要管理源代码就行了,一般项目多则几百K。使用maven的话,项目中不会包含依赖的jar文件。除要部署打包,才生成一个带所有依赖的文件(jar,ear,war),但这根本不会加入到版本控制中。
使用maven,所有本地项目的jar依赖都是共享的。每个项目依赖的第三方jar文件,在项目的pom.xml文件中进行定义,maven在执行某个goal时会按照local(本机repository,默认位置是~/.m2/repository/)->share(公司所建的共享repository)->remote(远程repository)的顺序一级级的查找项目依赖。
35 楼 kfc_davy 2009-01-21 22:16
34 楼 downpour 2009-01-17 11:14
你这篇文章的功能maven都有啊有依赖关系的类库你怎么解决?maven的继承功能你这种方法也无法实现。maven怎么用不来?你们讨论的帖子在那里,看看学习下
我最大的问题在于,maven是如何解决library的副本问题的?就是说,如果我某个项目,开很多个branch,是不是每个branch依然需要下载那么多的lib包?
依赖关系?一个项目起来的时候,难道项目经理的经验还不足以确定类库的依赖关系嘛?
33 楼 realghost819 2009-01-17 10:55
有依赖关系的类库你怎么解决?
maven的继承功能你这种方法也无法实现。
maven怎么用不来?你们讨论的帖子在那里,看看学习下
32 楼 limeng1028 2009-01-16 10:03
checkout共享类库,并将其导入到IDE中作为一个Library工程
这个有创新
31 楼 大铭AAA 2009-01-15 16:57
持续关注中......
30 楼 sunson468 2009-01-13 10:12
对于lib的管理也算是心得之言,看到很多留言对此提出疑问实在感到抱歉,如何管理每个人的想法不一样,每个项目的,或者项目与项目之间的关系不同,构架都可以变化的,楼主只不过是给个集中管理lib库的方法而已,虽然你也可以直接copy到目录里!
struts2没怎么用过,感觉跟struts1的版本相差很多,一直在用1,所以对2也没怎么关注,据说是强悍了很多功能,不过自己感觉还是自己扩充修改来的方便!
29 楼 thinkingall 2009-01-08 23:46
28 楼 bengan 2009-01-07 10:20
27 楼 snowolf819 2009-01-06 18:40
26 楼 javer 2009-01-03 20:17
25 楼 anders02 2008-12-31 12:27
反正我觉得这样做还算方便,至少不用几个项目整几个相同的包或者拷贝到服务器的lib下面,那样很讨厌的。
24 楼 dragonsoar 2008-12-30 13:24
这样的文章我感觉非常的好,简单、实用。
因简单而强大,我相信这句话是非常有道理的。
我现在在的一家公司就是用的maven,每次更改类都要打包。如果不打包就不能将class实时自动更新。公司架构师又写了个插件,不过又有同步上的BUG。
我相信我们集团已经因为打包的问题,至少浪费了半年的时间。
上面的环境配置实际上解决了我们日常开发中的大部分问题,非常经典。顶!
23 楼 iranger 2008-12-29 16:42
22 楼 downpour 2008-12-29 01:30
一个简单的问题,你用什么办法保证你所有的lib中的jar文件是兼容的。比如spring依赖的cglib,asm与hibernate依赖的cglib,asm版本不一致,而且众所周知,cglib版本之间兼容性不好。比如(这个只是比方,没有拷证),spring 2.5.4 orm开发时用的是hibernate 3.3.0.GA,你强行引入hibernate 3.3.1.GA,可能引入新的不兼容。
显然你没有读懂我的文章。也没有去下载我的svn地址上的library看看我的库到底是怎么样的。费心再给你解释一下。
1. 建立一个公共的库,并为这些库进行分类,在每个分类中,可能包含不同的library版本。比如说,cglib中可能会有不同版本的library,我们会把这些版本的library全都放到cglib这个分类中,用不同的文件名进行区分。
2. 当你具体做到某个项目的时候,我到底使用哪些jar包是由项目的具体情况而定的。比如说,某个项目,我需要用到Spring2.5.4和Hibernate3.3.0,那么我一定会为这个项目寻找一个同时兼容这2个jar包的cglib,测试通过后,加入到这个具体项目的classpath文件中。
3. 不同的项目所引用的jar包是不同的。所以,归根结底只要控制具体项目的classpath文件就能轻松做到jar包的版本管理。
所以,没有人会在add了Hibernate 3.3.0GA后,再去add一个Hibernate 3.3.1GA的jar包。这完全是你的误解。
21 楼 hantsy 2008-12-28 20:58
比如spring依赖的cglib,asm与hibernate依赖的cglib,asm版本不一致,而且众所周知,cglib版本之间兼容性不好。
比如(这个只是比方,没有拷证),spring 2.5.4 orm开发时用的是hibernate 3.3.0.GA,你强行引入hibernate 3.3.1.GA,可能引入新的不兼容。
20 楼 downpour 2008-12-25 13:09
这种library管理是脱了裤子放屁。。。
你的言语非常不文明,如果觉得不好,可以提出你的理由来,大家讨论,否则请自动删除你的回复。
19 楼 hantsy 2008-12-24 22:18
18 楼 dcgame 2008-12-24 11:01
17 楼 kyo100900 2008-12-23 17:08
classpath,jdk,IDE之类的东东没有必要截图的手把手教。
downpour 继续写吧,我相信后续的文章更加精彩
16 楼 you_meng 2008-12-23 13:52
15 楼 downpour 2008-12-23 12:59
本文并没有特别针对struts2的项目开发做什么介绍,其实这样的做法是对所有的同类型项目都适用的。唯一不同的就是容器的设置。
我并不希望写一份教程,手把手地去教一个框架怎么用,我相信我也不具备说struts2的每个细节,每个类的源码都去认真读过。
我希望的是通过一系列的文章,能够给大家一些学习开源框架的启示,同时总结一些开发中的实践。所以在一开始我会花费大量的口舌去讲概念,讲我们到底应该怎么去学,学什么,为什么要这么学。
至于开发环境的搭建,我个人是把它当作一个最佳实践的,因为至今为止,这样的开发环境配置是我见过最简单,可移植性最好的开发环境。如果大家有更好的方案和方式,都可以拿出来一起讨论一下。
14 楼 karlom 2008-12-23 12:33