Tom*_*Tom 15 java oop dao design-patterns
我查了很多关于DAO模式的信息,我明白了.但是我觉得大多数解释并不能说明整个故事,而且我的意思是你实际上在哪里使用你的DAO.例如,如果我有一个User类和一个能够为我保存和恢复用户的相应UserDAO,这是正确的方法:
控制器创建User对象并将其传递给UserDAO以将其保存到数据库
控制器创建User对象,并在其构造函数中,用户对象调用userDAO以将其自身保存到数据库中
这是一种代码味道,你缺少一个额外的类"UserManager",控制器会要求它创建用户.UserManager负责创建用户并要求UserDAO保存它
我真的觉得第三个选项是最好的,因为控制器负责的是将请求委托给正确的模型对象.你最喜欢的方式是什么?我在这里错过了什么吗?
kos*_*tja 14
根据我对DAO的经验,第一种方法是唯一正确的方法.原因在于它具有最清晰的责任并产生最少的混乱(好吧,一些非常受尊敬的程序员认为DAO本身就是混乱.Adam Bien认为原来的DAO模式已经在EntityManagerDAO和其他DAO中实现了大部分不必要的"管道")
方法2将模型绑定到DAO,创建"上游依赖".我的意思是通常模型作为单独的包分发,并且(并且应该)不知道它们的持久性细节.与您描述的类似的模式是Active Record模式.它在Ruby on Rails中被广泛使用,但在Java中并没有以同样的优雅和简洁的方式实现.
方法3 - 应该是什么意思UserManager?在您的示例中,Manager执行2个任务 - 它具有User工厂的职责,并且是持久性请求的代理.如果它是一个工厂,你需要一个,你应该命名它UserFactory而不在其上强加额外的任务.至于代理 - 您为什么需要它?
恕我直言,大多数名为...Manager有气味的班级.这个名称本身表明该课程没有明确的目的.每当我想要一个课程的冲动时...Manager,这是一个信号,让我找到一个更合适的名字或者仔细思考我的建筑.
| 归档时间: |
|
| 查看次数: |
11770 次 |
| 最近记录: |