问题描述
在我的应用程序中，我通常访问 DAO 层以获取/保存或更新其存储库中的对象，并且我使用 Service 层执行更复杂的操作
In my applications I usually access the DAO layer in order to obtain/save or update objects to it's repository, and I use a Service layer to perform more complex operations.
所以我的问题是:从 Controller 层访问 DAO 层是否正确(根据最佳实践和设计/架构模式)，还是我应该通过 Service 层绕过它?谢谢！
So my question is this: Is it correct (according to best practices and design/architecture patterns) to access the DAO layer from the Controller layer, or should I bypass it through the Service layer? Thanks!
推荐答案
理论上:在MVC架构模式的上下文中，数据访问层(DAO)和服务层之间没有明显的区别.服务层和DAO层都可以视为MVC中的模型".服务层可以很好地实现业务逻辑，复杂的验证等，但是它仍然是访问数据的层！只要您在Model，View和Controller对象之间保持清晰的关注点分离，从Controller对象访问DAO层就是正确的.
In theory: within the context of the MVC architectural pattern, there is no clear distinction between a data access layer (DAO) and a service layer. The Service layer and the DAO layer could both be seen as the "Model" in MVC. A Service layer may well implement business logic, complex validations, etc. - yet it is still a layer for accessing your data! As long as you maintain a clean separation of concerns between your Model, View and Controller objects, it would be correct to access the DAO layer from a Controller object.
在实践中:我已经看到了两种情况.如果您的小型应用程序具有简单的数据模型，则可以直接从Controllers使用DAO层.但是，随着业务逻辑变得复杂，或者如果您的模型由多个应用程序共享，则将业务代表和DAO排除在外以便重新使用组件，最大程度地减少更改时的影响，提高之间的灵活性将更为有意义.组件等.这取决于相关系统的技术架构.
In practice: I have seen both scenarios. If you have a small application with a simple data model, it would make sense to use the DAO layer directly from Controllers. However, as business logic gets complicated, or if your model is shared by more than one application, it would make more sense to factor out Business Delegates and DAOs in order to re-use components, minimize impact when changes are made, increased flexibility between components, etc. This would be dictated by the technical architecture of the system in question.
这篇关于从Controller层访问DAO层是否正确?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！