使用struts和hibernate的Dao层和业务逻辑
我有一个struts项目，我的客户给了我完整的业务逻辑类。他需要这个忘恩负义的人，昂首阔步，冬眠。
哪一种最好，要将业务逻辑放到我的Dao层，需要为业务逻辑添加一个附加的服务层。
一些strut项目我发现动作类直接访问道。
请建议我哪个更好choice.help高度赞赏。
谢谢，
共有3个答案
让Hibernate成为您的DAO层，并在其中包含业务规则的服务层之上编写一个服务层。这两者共同构成了MVC的模型部分。Struts操作是MVC的控制器部分。
我强烈建议将您的业务逻辑写入服务层，这样您的dao层只包含数据库交互，并且可以在任何时候重用。
另外，我建议您添加一个表示层（所有具有普通值的实体），该层将由UI层访问。
我的建议是保持Dao与您的业务逻辑保持一致，但所有与数据库相关的逻辑和定制都应该像所有hibernate逻辑一样在Dao层编写，并将结果转换到您的类中等等。。（当您使用Hibernate时）应该用DAO编写。
整个迭代、设置/获取、结果定制、准备、请求改进都应该作为hibernate查询的参数写入服务层。
另一层控制器应在服务层上工作，该服务层将接收请求并调用各自的服务方法，并提供生成的响应。
-
问题内容： 我目前正在使用带有Spring插件和hibernate的Struts2开发一个Web应用程序，并且在查看在线示例时，我看到了Service和DAO层的使用，现在才知道Service和数据访问对象层的真正用途是什么？如果服务层只是在调用DAO层的方法来执行CRUD操作。直接调用DAO层方法不明智吗？ 假设此示例为Dao和Service Layer 人员服务 人道 我的问题是，如果仅将服务
-
问题内容： 软件体系结构中的域对象和域服务是什么？我不熟悉它们，或者它们与业务逻辑层有何不同？ 问题答案： 不同的人以不同的方式使用这些术语，但这是我的看法： 1）“业务”和“域”大致是同义词。“域”更为通用，因为它不会假设您正在编写业务应用程序。因此，如果我们正在编写科学应用程序或游戏，则可能更喜欢将代码的相关部分称为“域”代码，而不是“业务”代码。因此，在本说明的其余部分中，我将使用“域”，因
-
在我的示例中，我有一个Hibernate实体和一个DAO。 当我以这种方式使用DAO时 数据库中只保存了一行（Action2）。当我删除注释时，两行（Action1和Action2）都被保存（这是我需要的行为）。我的问题是服务层上的事务注释如何影响事务（方法executeTransaction（））的执行。为什么没有服务层上的事务性注释，这两行都保存在数据库中，而只有最后一行与此注释一起保存？
-
我正在寻找用Struts2和Hibernate实现分页的想法。例如，我的表包含太多行，应该是因为我一次只能看到20行。带有和按钮。
-
问题内容： 如果有什么问题请指正。 现在，当我们将Spring DAO用于ORM模板时，当我们使用@Transactional属性时，从外部而不是在方法内部调用该方法时，我们将无法控制事务和/或会话。 延迟加载可节省资源-减少对数据库的查询，减少将所有集合保持在应用程序内存中的内存。 因此，如果lazy = false，则在链接集中有10,000条记录的情况下，所有相关联的集合都将被提取，这并不是
-
问题内容： 我正在设计一个基于JPA / Hibernate，Spring和Wicket的新应用。我对DAO和Service层之间的区别还不清楚。根据维基百科，DAO是 一个为某种类型的数据库或持久性机制提供抽象接口的对象，提供某些特定的操作而不公开数据库的详细信息。 我想知道DAO是否可以包含与数据访问无关的方法，但是使用查询执行起来会更容易吗？例如，“获取在一组特定机场上运营的所有航空公司的列