Model类和DAO类之间的区别

huangapple go评论80阅读模式
英文:

Difference between Model classes and DAO classes

问题

这是您要翻译的内容:

我对基于Java的Web应用程序还不熟悉。我必须使用MVC结构创建一个动态Web项目。到目前为止,我创建了三个包和一些Java类,如下所示。我对这些事情有一些疑问:

  1. 有人可以解释一下模型类和DAO类之间的区别吗?

  2. 因为我正在使用MVC结构,我真的需要为DAO创建一个单独的包,还是将所有DAO类的实现放在模型类内部也可以?因为MVC表示模型-视图-控制器。

Model类和DAO类之间的区别

模型类
Model类和DAO类之间的区别

DAO类
Model类和DAO类之间的区别

英文:

I'm new to java based web applications. I have to create a dynamic web project using MVC structure. So far I created three packages and some java classes like below. I have some doubts about these things

  1. Can someone explain the difference between model classes and DAO classes

  2. Since I'm using MVC structure do I really need to create a separate package for DAOs or is it okay to put all the DAO class implementations inside the Model class ? Because MVC means Model-View-Controller

Model类和DAO类之间的区别

Model Class
Model类和DAO类之间的区别

DAO class
Model类和DAO类之间的区别

答案1

得分: 6

DAO类与持久化系统(通常是数据库)和控制器进行交互,将模型类的实例在它们之间移动。模型类是对你正在处理的现实世界对象的表示(例如,医院管理应用中的患者、医生和预约,或银行应用中的客户、账户等)。理想情况下,模型类甚至不应该知道有DAO的存在。因此,把它们放在不同的包中是有意义的,因为它们是不同的概念。需要注意的是,即使你的应用程序遵循MVC模式,这并不意味着你的应用程序只关注于视图、模型和控制器。你可能还有其他关注点,比如持久化,它们属于自己的层。

另外一个你可能想做的事情是使用数据传输对象(DTO)。它们是模型实体的另一种表示(但应放在它们自己的包中,而不是模型包中),但DTO不必具有与模型类相同的属性。DTO是控制器应该传递给视图的内容(反之亦然)。这样,视图就不知道你的模型,也不会向视图层暴露不想要暴露的模型类属性。例如,如果你有一个用于表示客户的模型类,其中包含有关其信用卡号的信息,但你有一个视图不需要显示该信用卡号的情况,你可以创建一个DTO,其中包含其他客户数据,并在该视图中使用它,而无需将不需要的数据发送到视图中。

英文:

DAO classes talk to both your persistence system (generally a database) and your controller, and move instances of your model classes between them. Model classes are a representation of the real world stuff that you're working with (patients, doctors and appointments for a hospital management app, for example, or clients, accounts and so on for a bank app). Ideally, your model classes shouldn't even know that there's a DAO. So yes, it makes sense to put them in different packages since they are different things. Do note that even if your app follows the MVC pattern, that doesn't mean your app only concerns itself with the view, the model and the controller. You can and usually will have other concerns, like persistence, that belong in their own layer.

One other thing you probably want to do, while we're at it, is have DTOs. They are an additional representation of your model entities (but they should go in their own package, not the model package), but DTOs needn't have the same properties as your model classes. DTOs are what the controller should feed to the view (and viceversa). That way, your view doesn't know about your model, and you don't expose to the view layer any properties of your model classes that you don't want to expose. For example, if you have a model class for customers with information about their credit card number, but you have a view that doesn't need to show that credit card number, you can create a DTO that has the other customer data and use it for that view without sending the unneeded data to your view.

答案2

得分: 5

> 有人可以解释一下模型类(model classes)和数据访问对象类(DAO classes)之间的区别吗?

这些是非常不同的东西。
DAO 是面向 CRUD 的数据服务(读取/创建/更新/删除数据),而模型是表示数据的对象。DAO 使用模型,但反过来不一定成立。

> 由于我正在使用 MVC 结构,我真的需要为 DAO 创建一个单独的包,还是把所有 DAO 类的实现放在模型类内部也可以?

因为 DAO 和模型是两个不同的概念(虽然相关),将它们的类分开放在两个不同的包中似乎更清晰。

英文:

> Can someone explain the difference between model classes and DAO
> classes

These are very different things.
DAO is a CRUD oriented data service (read/create/update/delete data) and model are objects representing data. DAO uses Model but not the reverse.

> Since I'm using MVC structure do I really need to create a separate
> package for DAOs or is it okay to put all the DAO class
> implementations inside the Model class ?

Because DAO and models are two different concepts (while related), it appears clearer to separate their classes in two distinct packages.

huangapple
  • 本文由 发表于 2020年8月22日 15:29:35
  • 转载请务必保留本文链接:https://go.coder-hub.com/63533657.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定