java-web应用中包,接口的设计

java web 应用中包,接口的设计java web 应用中包，接口的设计.txt 其实全世界最幸福的童话，不过是一起度过柴米油盐的岁月。一个人愿意等待，另一个人才愿意出现。感情有时候只是一个人的事，和任何人无关。爱，或者不爱，只能自行了断。采用标准的架构:描述从低层到高层 首先是系统分析，找出你需要什么功能，然后按照下面的步骤执行: 数据库层:数据库层就是 SQL 语句、数据库、表、视图、触发器等等的创建和管理。这一层和 JAVA 无关，但是却是最重要的一层 持久层(Hibernate、JPA、JDBC):这一层的目的很明确，就是 ORM，这里还不用你定义接口和类，你只要使用框架就可以了。 DAO 层(Data Access Object):这一层比较重要点，这里定义的都是对一些最原始的类进行操作的方法 打个比方: 我们有一个 Account 类，用来表示账号，那么对应有一个接口 public interface AccountDao Account create( Account account ); /创建一个 Account 账号 void update( Account acconut ); /修改账号 void delete( int id ); /通过 ID 删除 Account void find( int id ); /通过 ID 找到 Account 然和我们有具体的实现 public class AccountDaoImplForHibernate implements AccountDao /这里实现 AccountDao 所有的接口 这里要说明一下，为什么要这个 DAO 层，我直接操纵 Hibernate 框架去完成不就可以了么,为什么要用一个 AccountDao 在从中进行阻拦。 这就是 Java 中接口威力所在，定义了一个接口，你就不用管下面的具体实现是用那个框架实现的，总之实现就可以了。因为软件的目的是要重用，而在 WEB 开发中，每个网站都有自己不同的要求，所以也就让人觉得重用不重用不关我事情:“反正老子就用 Hibernate 管理数据库了，下次再开发类似的大不了我重写，反正又不难。”很明显，这种思想很实用，似乎马上就能进行开发，但是这明显是错误的思路。 根据我开发 B/S 系统的经验(容我这么说吧，其实我也没弄过几个)，我喜欢利用 Dao 层把 WEB 框架和 ORM 框架隔离开来进行开发。不知道大家在开发 WEB 站点的时候有么有觉得，每次修改完一个类都得重新部署，每次部署都得重新加载数据源、连接数据库、配置持久化框架稀里哗啦一大堆事情，部署一个项目往往用掉十几甚至几十秒。但是如果我们能利用 Dao 层进行隔离，那么情景就又是另外一个样子。 我们可以伪造一个数据库，没错，是伪造的，用了 HashMap对数据库进行简单的模拟。具体来说，就是为测试写一个类去实现 AccountDao 接口，但是这个类不再连接数据库，而是直接对伪造的数据库，也就是 HashMap 表进行操作 public class AccountDaoImplForTest /具体实现 这样部署起来就快多了。 而对于 AccountDaoImplForHibernate 的测试，可以通过 J2SE 应用程序完成，同样也省下了部署 WEB 到 J2EE 服务器的时间。效率第一哈 顺便说说这一层应该抛出的异常。为了屏蔽掉 Dao 的具体实现，我们很有必要为 Dao 层自己定义一些异常，用来替代由 Hibernate、JDBC 他们抛出的异常。这样对于 Dao 的上一层 Service 层来说，只看到 Dao 的东西，其他什么都没看见，也不知道这个 Dao 具体是 Hibernate 呢还是 JPA 呢还是 JDBC 同样的道理，我们来看 Service 层 Service 层:在 Service 层中我们定义这样的接口 public interface AccountService Account register(Account account); /注册 Account login( String username, String password ); /登录 void modify( Account account ); /修改 Account find( int id ); /通过 ID 获取 Account Account delete( int id ); /删除 Account 乍看之下，似乎 Service 层和 Dao 层差不多，无谓就是多几个方法，那我直接定义到 Dao 层不可以吗,答案肯定是不可以，真是废话，可以我就不写了。但还是要说说理由:很简单，Service 层隔离了业务需求变化和数据库之间的关系。也就是说，不管上面的业务逻辑怎么变化，你只用修改 Service 层的代码就可以了，Service 通过调用 Dao 来实现对数据库的操纵，很显然 Dao 不知道 Service 的存在，所以 Service 怎么变 Dao 都不用去理会。除非 Service 提出了 Dao 没有实现的要求，比如说 Service 需要获取所有账号的人数，而我们当初在系统分析的时候没有做好，没在 Dao 层预留一个方法去获取所有账号的数量，那么这个时候就得被迫修改 Dao层了，但是，也仅仅只是修改到 Dao 层而已，由于 Dao 层的功劳，你还不必去修改数据库。 所以说，开始项目之前对整个项目进行详尽的业务分析对你定接口是有很直接的因果关系的，分析没做好，那么接口就得整天改，这个时候你还不如不用接口呢 在 Service 层抛出的异常也有讲究:在 Service 层，我们只能抛出业务逻辑上的异常，像AccountExistedException(账号已存在)异常啦、UsernameNotFou