问题描述
|
关闭。这个问题是基于意见的。它当前不接受答案。
解决方法
理论上：在MVC架构模式的上下文中，数据访问层（DAO）和服务层之间没有明显的区别。服务层和DAO层都可以视为MVC中的“模型”。服务层可以很好地实现业务逻辑，复杂的验证等，但是它仍然是访问数据的层！只要您在Model，View和Controller对象之间保持清晰的关注点分离，从Controller对象访问DAO层就是正确的。
在实践中：我已经看到了两种情况。如果您的小型应用程序具有简单的数据模型，则可以直接从Controllers使用DAO层。但是，随着业务逻辑变得复杂，或者如果您的模型由多个应用程序共享，则将业务代表和DAO排除在外以便重新使用组件，最大程度地减少更改时的影响，提高之间的灵活性将更为有意义。组件等。这将由相关系统的技术架构决定。
,我认为，如果不需要从服务层进行任何类型的处理，那么让控制器层直接访问DAO就没有问题。但实际上，它至少应该做某种处理，例如在弄乱数据库之前服务器先确认输入数据。
,您应该绕过它到服务层。
这样做的原因：
稍后，您可以将事务管理放在此服务层中。
如果您希望将所有调用DAO的代码放入Service中，以将Controller Layer完全更改为其他框架（例如，将Struts更改为Spring MVC），则重构起来会更容易（您只需要Spring MVC来调用您的现有服务）。想象一下，如果您必须将所有DAO调用都放入Spring MVC层。
,我想我是这里的偶像破坏者。我同意迄今给出的答案，即绕过服务层原则上是好的，但以我的拙见，这在实践中不是。
主要原因是很难预料何时会引入业务逻辑。例如，我认为\“ logging \”是业务逻辑。如果要引入日志记录或日记记录或限制访问，则不想在DAO层中进行。但是，如果我有绕过DAO层的代码，则现在需要重构所有这些代码。
我经常发现DAO层还有另一个优点。我可能想将某些操作公开给服务层，而不是公开给它之上的任何层。
举例来说，我可以想象一个DAO层返回加密的密码，但是一个服务层仅允许您确定所传递的加密密码是否与数据库中的密码匹配。我不希望控制器层能够获取有效的加密密码-我看到了不必要的暴露。
因此，尽管我可能会同意，如果您知道该死的，请确保永远不会引入业务逻辑（例如我所描述的），并且如果您有零需求，则需要隐藏一些数据访问操作，同时公开其他数据……一定要将DAO层暴露在更高的层上。
我的观点是，在实践中，您不能“知道”这一点，也不应该假设这一点。