这是我开始工作的一次总结，其实说真的，在传智播客学的东西还是很有用的。我
在传智播客学习的时候每一天都是非常努力的去学习。现在开始工作了，真的有点
幸运，我进入公司后其实还是有点不是很习惯，因为所处的是一个陌生的环境，陌
生的同事。
在进入公司之后的开始就接到一个项目。公司的领导对我很看重，因为在我
面试的时候面试官对对我的技术还是比较佩服的。所以刚进入公司就开始接手项目了。目前在公司里面每天觉得很充实，因为每天都会接触一些新事物，其实有很多也是我们在传智没有学过的，但是我以前
的基础还可以，所以接触的这些新的技术很快就可以适应了，再加上项目组的其他
人的帮助，我觉得自己以后的发展还是很不错的。每次在开讨论会的时候，我的上
司总是说让我上去给大家讲，一开始我觉得很害羞，后面的几天就习惯了，开始觉
得自己的语言表达能力也很不错了，在我们一个项目组中，我是最后一个去的，其
他的几个都是有一两年的工作经验的，经验上我没有资格和他们相比，但是我的技
术还是
早就应该写这篇总结了，因为目前在学习巴巴运动网时间比较紧，所以就一直拖到了今天才写。来传智播客学习快四个月了，学习的内容也基本接近了尾声了，现在感觉还是比较不错的，至少让我学习到了很多的知识。来传智播客之前也是想了很久的，毕竟就是害怕花了钱而没有学会知识。还有20多天我们的课程就结束了，就可以理直气壮的去找工作了。以前是没有底气的，但是今天我是很有信心的。来传智播客学习真的没有后悔。回想起当初的迷茫，真是有点可笑，我真正的接触
在Spring中整合Hibernate也是需要掌握的，整合的过程比整合Struts相对来说要简单一些，首先还是我们要实现的目标是整合，思路就是让spring容器来管理SessionFactory，这样就可以使用Spring的声明式事务了。
在 Spring 中配置 SessionFactory，可以利用Spring提供的
LocalSessionFactoryBean 工厂 Bean, 声明一个使用 XML 映射文件的 SessionFactory
实例。需要为该工厂 Bean 指定 configLocation 属性来加载 Hibernate 配置文件。例如：
<bean id='sessionFactory'
class='org.springframework.orm.hibernate3.LocalSessionFactoryBean'>
<property name='configLocation'
value='hibernate.cfg.xml'></property>
</bean>，这样就可以在Bean中注入SessionFactory了。但是SessionFactory需要注入一个DataSource才可以，所以还要声明一个DateSource来进行注入，为了将数据库的信息以及数据库连接池的信息配置在配置文件里面，所以使用的<context:property-placeholder
location='classpath:
Spring和Struts
1的整合是我们经常会使用的，因为我把整合的步骤大致的总结一下，主要是包含各种整合的方法以及每一种方法的利弊。
首先是要看的是如何将Spring整合一般的的Web应用，也就是说即使不使用Struts也是可以使用Spring的，当然这种整合的方法也适合于Struts的应用中。首要是要注册一个Spring提供的一个监听器，注册好了之后就可以使用Web应用服务器来进行启动Spring的容器，也是ApplicationContext的实力，然后就可以使用这个对象来获取Spring容器来管理的Bean。注册监听器的代码是：
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
为了可以让这个监听器来加载Spring的配置文件，还需要指定Spring配置文件的位置。
<context-param>
<param-name>contextConfigLocation</param-name>
<par
今天学习的是UML，UML是(United Modeling
Language, 统一建模语言): 是一种基于面向对象的可视化建模语言。UML 采用了一组形象化的图形(如类图)符号作为建模语言,
使用这些符号可以形象地描述系统的各个方面。UML 通过建立图形之间的各种关系(如类与类之间的关系)来描述模型。
UML 中一共有 10
种图，其中的静态模型图有：类图、对象图、包图、组件图、部署图，动态模型图有用例图、时序图、协作图、状态图、活动图。其中的类图是最重要的，还有就是用例图和时序图也是要求要掌握的。UML
中的关系主要包括 4
种：关联关系(association)、依赖关系(dependency)、泛化关系(generalization)、实现关系(realization)。
首先了解一下关于用例图，用例图(Use Case
Diagram): 也称为用户模型图, 是从软件需求分析到最终实现的第一步, 它是从客户的角度来描述系统功能。用例图包含 3
个基本组件: 参与者(Actor), 用例(Use Case), 关系。参与者(Actor):
与系统打交道的人或其他系统即使用该系统的人或事物，在 UML 中参与者用人形图标表示。用例(Use Case):
代表系统的某项完整的功能. 在 UML 中使用一个
11. Spring的AOP（基于注解的方式）
接下来就是关于Spring的AOP了，这是Spring的最经典的内容了。AOP(Aspect-Oriented
Programming, 面向切面编程): 是一种新的方法论, 是对传统 OOP(Object-Oriented
Programming, 面向对象编程) 的补充。AOP 的主要编程对象是切面(aspect), 而切面模块化横切关注点。在应用
AOP 编程时, 仍然需要在定义公共功能, 但可以明确的定义这个功能在哪里, 以什么方式应用, 并且不必修改受影响的类.
这样一来横切关注点就被模块化到特殊的对象(切面)里。AOP 的好处是每个事物逻辑位于一个位置, 代码不分散,
便于维护和升级，业务模块更简洁, 只包含核心业务代码。要在 Spring 应用中使用 AspectJ 注解, 必须在
classpath 下包含 AspectJ 类库: lib\aspectj\aspectjrt.jar 和
aspectjweaver.jar，要在 Spring IOC 容器中启用 AspectJ 注解支持, 只要在 Bean
配置文件中定义一个空的 XML 元素 <aop:aspectj-autoproxy>，同时将 aop Schema 添加到
<beans> 根元素中。当 Spring IOC 容器侦测到 Bean 配置文件中的
<aop:aspectj-autoproxy> 元素时, 会自动为与 Aspec
5. Spring的Bean的自动装入
Spring IOC 容器可以帮助自动装配 Bean. 需要做的仅仅是在
<bean> 的 autowire 属性里指定自动装配的模式。autowire
属性的值有一下几个值，byType(根据类型自动装配): 若 IOC 容器中有多个与目标 Bean 类型一致的
Bean，在这种情况下，Spring 将无法判定哪个 Bean 最合适该属性,
所以不能执行自动装配。byName(根据名称自动装配): 必须将目标 Bean
的名称和属性名设置的完全相同。constructor(通过构造器自动装配): 当 Bean 中存在多个构造器时,
此种自动装配方式将会很复杂。所以最后一种不推荐使用。当然针对这种自动装配还是不建议使用的，因为在实际的开发过程中很少使用，这样做虽然省事，但是不利于维护。在
Bean 配置文件里设置 autowire 属性进行自动装配将会装配 Bean 的所有属性. 然而, 若只希望装配个别属性时,
autowire 属性就不够灵活了。autowire属性要么根据类型自动装配, 要么根据名称自动装配, 不能两者兼而有之。
Spring 2.5 对自动装配特性进行了增强. 可以通过注解 setter
方法, 构造器, 字段, 甚至任意方法来装配特定的属性。
1. Spring的概述
Spring 是一个开源框架，Spring 为简化企业级应用开发而生， 使用 Spring
可以使简单的 JavaBean 实现以前只有 EJB 才能实现的功能。Spring 是一个 DI 和 AOP
容器框架。IOC(Inversion of Control): 其思想是反转资源获取的方向.
传统的资源查找方式要求组件向容器发起请求查找资源. 作为回应, 容器适时的返回资源. 而应用了 IOC 之后,
则是容器主动地将资源推送给它所管理的组件,
组件所要做的仅是选择一种合适的方式来接受资源，这种行为也被称为查找的被动形式。DI(Dependency Injection):IOC
是一种通用的设计原则, 而 DI 则是具体的设计模式, 它体现了 IOC 设计原则。在 DI 模式里,
容器以一些预先定义好的方式(例如: setter 方法)将匹配的资源注入到每个组件里。因为 DI 是 IOC 最典型的实现, 所以
DI 和 IOC 经常混用。
2. Spring的依赖注入
在 Spring 的 IOC 容器里配置
Bean，依赖注入方式只要有两种：setter 注入: 最流行的 DI 类型。容器通过组件里的 setter
方法注入依赖。优点是setter 方法可以自动生成; 简单。缺点是组件使用者或许
今天继续学习使用Jbpm来制作OA项目，今天的内容比较抽象，设计实体是最具有技术含量的，很多的程序也许在实体已经确定的时候非常好写了。今天的主要的内容是表单流程实例的设计，昨天的内容是建立了表单模板，今天就是在昨天的基础上使用表单模板来建立表单实例，然后使用JBPM来进行流程实例的测试，在流程实例中流转的数据就是一个表单实例，并且这个表单实例是封装了相关业务数据信息的表单，为了能够在流程实例的每一个环节都能进行访问到表单中的数据，因此将表单实例放在流程变量中，这样在流程开始的时候进行放在流程变量中，在以后的流程中就可以访问了。
首先我们要看一下今天的内容需要设计几个实体，其实我们的需求就是要能够封装在流程中流转的实例对象来封装流转的数据。在这里看来只需要一个实体就可以了。我们暂且定这个实体的名字叫做FlowFormInstance,接下来考虑下可能和这个实体相关的关联的实体以及它们之间的关系。表单实例肯定是属于某一个表单模板的，它们之间的关系是多对一的关系。每一个表单实例都是属于一个申请人的，因此又需要有一个Employee的实体与之相
今天还是继续学习使用Jbpm来制作OA项目，今天的内容相对来说还是比较难的，因为在开发的过程中遇到了大量的没有见过的一些步骤因此要学习新的技术方法来实现，说是新的技术根本不算，只是我们以前学习的一些知识的灵活运用，如果真正的会用了一种技术那将是相当了不起的。
今天的重点就是关于表单模板的配置管理。每个表单模板对应一个流程定义，但不是某个具体版本的流程定义。应保存流程定义的名称，在使用时是取指定名称的最后一个版本来使用。表单的模板在指定地址时，是按照制定好的规则，比如开头的'/'代表应用程序的路径。可以使用打开一个窗口选择某个文件的效果。表单实体要能存储所有类型表单中的业务信息，可以使用一个Map属性来存放，其key是String型，value是Serializable类型，这样就可以存储各种表单业务数据了（String/Date/Number等）。在进行实体定义的时候新建了两个实体对象：FlowformConfig和FlowformFieldConfig，这两个实体之间的关系是一对多的关联关系。相应的映射文件也就比较简单了，只是一个一对多的映射。其实难点就是如何将页面中定制的表单的信息进行相应的存储，放在这个Flow
发博文
加载中…