问题描述
在我的应用程序中，我通常访问 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 层是否正确(根据最佳实践和设计/架构模式)，或者我应该通过服务层绕过它?谢谢！
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) 和服务层之间没有明确的区别.Service层和DAO层都可以看作是MVC中的模型".服务层可以很好地实现业务逻辑、复杂的验证等 - 但它仍然是一个用于访问您的数据的层！只要您在模型、视图和控制器对象之间保持清晰的关注点分离，从控制器对象访问 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.
在实践中:这两种情况我都见过.如果您有一个具有简单数据模型的小型应用程序，那么直接从控制器使用 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层是否正确?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！