Struts+Hibernate实例.pptVIP

Struts+Hibernate实例超市管理系统 1.系统需求分析和初步设计 系统需求分析 a.用户登陆系统,退出系统 用户要进行任何操作,都必须首先登陆,只有登陆成功后,才能进行相应的操作,用户在完成相应的操作后,为了安全起见,应该退出系统 b.收入管理 用户可以添加收入或者修改收入 通常是一个营业日的结束,用户收集一天的收入信息,这些信息通常是按照不同的部门来归类的,并且相应的数据添加到系统中.如果用户发现输入的收入信息有错误,应该可以修改该笔收入 2.系统构架说明 a.构架说明 从整体结构看,本系统一样是严格按DAO层,业务逻辑层,控制器层的方式进行分层,系统各类的组件被封装在自己的层内.DAO组件全部被封装在DAO层内,提供了DAO工厂管理DAO组件,业务逻辑组件被封装在业务逻辑层,由业务逻辑组件提供管理 3.实现Hibernate持久层 a.持久层的pojo b.编写po的映射文件 c.配置Hibernate配置文件 4.实现DAO层组件 在静态的面向对象的语言中,接口是一种很好的解耦方式,它体现的是一种规范和实体分离的原则.当A组件依赖于B组件时,让A组件不直接依赖于B组件的实现,而是依赖于B组件的接口,从而将A组件和B组件之间的耦合从代码层次提高到接口层次 a.编写DAO接口 　 b.实现DAO组件 　 c.使用配置文件解耦 　　DAO工厂负责解析DAO组件的配置文件，根据DAO组件的实现类来 　　创建DAO组件．在程序中获得了DAO组件实现类的字符串后，可以 　　通过反射来生成DAO组件的实例 d.使用DAO工厂管理DAO组件(解析xml 工厂模式) 5.实现业务逻辑层 a.业务逻辑组件和DAO组件 在DAO模式下，业务逻辑组件完全依赖于DAO组件，这种依赖 是一种单向依赖 实际情况是，DAO组件被分离成两个部分:DAO接口和DAO实现 类．业务逻辑组件依赖于DAO接口,并不依赖DAO实现类. 当DAO组件的实现改变时，业务逻辑组件的实现类并不需要改 变．只有当业务DAO接口也发生改变时，业务逻辑组件的实现 类才可能要发生改变 b.业务逻辑层的Session和事务 系统的事务控制应该放在业务逻辑方法中进行控制，Hibernate Transaction是一个持久层的API,必然会导致业务逻辑层不能彻 底与持久层API分离,这是所有在代码中控制事务逻辑都不可避 免的问题 c.业务逻辑组件的接口定义 业务逻辑对象通常是对DAO组件的正面封装，因此通常多个 DAO组件被封装成一个业务逻辑组件.一个系统到底需要多少个 业务逻辑组件呢？通常而言，系统的每个模块对应一个业务逻 辑组件，每个业务逻辑方法用于一个用户请求． d.实现业务逻辑组件 为上面的业务逻辑接口提供一个实现类，该实现类实现业务 逻辑组件接口中定义的所有方法．大部分情况下，每个业务 逻辑方法用于响应一次控制器的调用，当然，在某些情况下 每次控制器也会调用多个业务逻辑方法 如果用户请求希望得到响应是逻辑不可分的，则应该尽量通 过定义一个业务逻辑方法来响应控制器调用．如果希望更好 的代码复用，可以将多个业务逻辑方法中的共有部门定义成 一个工具方法．这个工具方法仅仅作为其他业务逻辑方法的 支持，并不暴露给控制器调用 当实现一个业务逻辑方法时，通常都涉及到需要调用的多个 DAO方法,虽然业务逻辑方法的实现有很多种变化，但实现一 个DAO方法的步骤依然一致: 1.通过调用DAO工厂获取DAO组件实例 2.通过HibernateUtil工具获取Hibernate Session实例 3.通过Session打开Hibernate Transaction 4.在事务上下文，多次调用相关DAO方法实现业务逻辑方法 5.完全实现业务逻辑方法后，提交事务 6.如果实现业务逻辑方法中出现异常，回滚事务 业务逻辑组件直接依赖于多个DAO组件，业务逻辑组件也是 对DAO组件的正面封装.所有需要被控制器调用的方法都通过 业务逻辑组件暴露，让控制器调用业务逻辑方法即可. e.使用配置文件管理业务逻辑组件 f.实现业务逻辑组件工厂 对比业务逻辑工厂和DAO工厂，发现两者的功能实际上非常 相似．实际上，可以将业务逻辑组件和DAO组件配置在同一 个文件中，并使用同一个工厂进行管理．而且，业务逻辑组 件需要依赖于DAO组件,如果在配置文件中配置这种依赖－－ 那就是Spring的核心机制了． ６．实现Web层逻辑　 a.Web层处理机制 b.配置ActionServlet c.配置load-on-startup Servlet * * c.超市管理人员还应该可以增加供货商,并对供应 商进行管理 供货商的信息包含供货商名称