dao层接口与xml文件名必须一样吗

Posted 2023-03-29

dao层接口与xml文件名是必须要一样，到层接口与文件名要一样，才能操作接下来的东西，才能编写程序和文件 参考技术A dao层接口与xml文件名必须一样吗对的这个必须是一样的他的一个层接口和文件名呢必须是一样的只有这样一样才能匹配的进行一个使用所以他是这样的一个设置没有问题 参考技术B dao层接口与xml文件名必须一样吗对的这个必须是一样的他的一个层接口和文件名呢必须是一样的只有这样一样才能匹配的进行一个使用所以他是这样的一个设置没有问题 参考技术C Dll肯借口，吸ml文件名必须一样吗，这个文件名必须是一样的因为。不同文件名后缀是无法。共同协作运行的。

为何有DAO与Service层？为何先搞Dao接口在搞DaoImpl实现？直接用不行吗？

转自

http://blog.sina.com.cn/s/blog_4b1452dd0102wvox.html

 

我们都知道有了Hibernate后，单独对数据的POJO封装以及XML文件要耗损掉一个类（Orz意思是你需要精力写一个类）。然后，在大部分的服务中，我们又需要单独写一个Dao接口，并加个DaoImpl实现来操作数据库（好吧，再耗损2个类）。紧接着，我们发现其实Service层也要单独写一个类（再加1个）。

　　一共4个类外加1个xml……这不是作死么，5个文件。人家好端端地写PHP可能在一个php页面就完成全部功能了。显然，这么分工，得项目达到一定情况下，才有其适用性的。一个初步的设想是，由运维部分的数据库管理员（Database Administrator，简称DBA）提供设计好的表，并用相关Hibernate工具生成相应的POJO类与XML文档。（DBA主要负责业务数据库从设计、测试到部署交付的全生命周期管理）。

　　这样，对于开发人员来说，就可以尽情操作通过Hibernate获取的POJO类了。

　　对于单独分出Dao层与Service层的一些解释：

　　一个DAO单独对1个表进行操作。

　　一个Service可以操作几个DAO。

分层分析：那么这就意味着在几个大型数据库操作的时候，Service就能派的上用场。是不是这样分的？对于写入数据库的数据检查，交给Dao来。对于整个逻辑判断，交给Service来，例如在这张表找到了这个id字段，在那个表没找到，所以应该拒绝这项写入更新服务。

　　无论是哪种持久化存储， 数据访问对象（或称作为DAO，即Data Access Objects）通常都会提供对单一域对象的CRUD （创建、读取、更新、删除）操作、查询方法、排序和分页方法等。Spring Data则提供了基于这些层面的统一接口（CrudRepository，PagingAndSortingRepository）以及对持久化存储的实现。

 

Service和DAO的接口之有无：

　　接口是一种契约，它可以有多种实现。所以接口之有无取决于具体实现是否需要多样化。如果铁定一种DAO或一种Service只有一种实现，那么抽象出接口的意义不大（目前还无法想出Service的不同实现带来的好处）。然而一些大型应用或许需要DAO和Service的多种实现（比如帐户的DAO，可能需要一种Hibernate实现、一种CMP实现和一种JDO实现），为了向上一层隐藏具体实现类，需要采用接口。

　　隐藏具体实现类的创建过程，这有两种方法：一是实用工厂方法，代价是代码量大（每个DAO和Service一个工厂）。二是使用Spring的IoC，实现依赖注入，不需要写额外的代码，这也是引入Spring的理由之一。

 

 

参考资料：

ＪＤＯ的架构作一个简单的介绍

 

只有一些很精通JDBC的高手才会用到JDBC3.0中的高级功能。因此，采 用JDO也可以帮助我们在不了解JDBC3.0规范的情况下提高性能和效率。换句话说，JDBC技术本身就是一件很复杂的东西，要想优化性能的 话，很多JDBC技术和数据库技术是需要使用的，比如inner join, left/right outer join, Batch update，等等。这些对开发人员的技术要求很高，一方面要精确理解每种技术的应用范围和实际使用的注意事项，另一方面代码也会比较复杂。因此，既然有 众多的有经验的JDO厂商在做这些事情，我们又何必再花功夫呢？

 

DAO和Service层的一些解释

Service之有无这一点我的看法未必正确,我的脑海现在有两种构建业务层的模式:    

　　模式1——Service + DAO,即DAO中只做CRUD及类似的简单操作(称之为功能点,不包含业务逻辑),Service中通过调用一个或多个DAO中的功能点来组合成为业务逻辑.Service的数量应该由功能模块来决定。在这种模型中业务逻辑是放在Service中的,事务的边界也应该在Service中控制. 当然,直接在Service中控制事务会引入非业务逻辑的代码,幸好spring的AOP可以解决这个问题,这也是引入Spring的原因之一。如果说到缺点,就在于对某些对象的操作就是简单的CRUD，Service层显得累赘。

　　模式2——Service + BO, 而BO = DAO + 业务方法, 在原先DAO的基础上添加业务方法,形成BO对象。需要注意的是BO中的业务方法往往是针对一个实体对象的，如果需要跨越多个实体对象，则方法应该放在Service中。举例来说，一个简单的银行帐户管理系统，创建帐户这个BO对象，里面可以有修改密码，取钱等业务方法（不难看出，这些方法都只对单个帐户对象进行操作）。现在需要添加一个转账方法，就应该放在Service中。

　　这里Service和BO的关系是什么样的呢？再举一例：以国家行政机关为例：粮食局负责收粮，卖种子等，建设部负责审批土地买卖，建设公路等，这都是行政部分份内的事儿。突然某地发了水灾，救灾时需要粮食局开仓放粮，建设部修建临时房屋，如何协调两个部门？就需要成立专门的救灾委员会，由救灾委员会出面对两个部分的资源进行调拨。这里两个部分就是BO，而救灾委员会就是Service。不知我的意思是否表达准确了，呵呵。     模式1的在划分Service和DAO时界限清晰，但会带来一些无必要的代码。

　　模式2的划分相对复杂，然而可以提高编码效率。当然小规模的应用中，没有Service，完全是DAO或BO也是可以接受的。

 

 JAVA中Action层, Service层 ，modle层 和 Dao层的功能区分

Dao主要做数据库的交互工作

Modle 是模型 存放你的实体类

Service 做相应的业务逻辑处理

Action是一个控制器

Action像是服务员，顾客点什么菜，菜上给几号桌，都是ta的职责；Service是厨师，action送来的菜单上的菜全是ta做的；Dao是厨房的小工，和原材料(通过hibernate操作数据库)打交道的事情全是ta管。对象的调用流程：JSP—Action—Service—DAO—Hibernate—数据库。（粗体是自己需要码代码的）

PS：所以我觉得在之前SpringMVC的例子中，HiFirstApp就是一个JSP与Action的集合体。它调用了BookService，然后BookService调用了BookDao。