GRASP的Information Expert和MVC的Modell是否相同? [英] Is Information Expert from GRASP and Modell from MVC the same?

查看:98
本文介绍了GRASP的Information Expert和MVC的Modell是否相同?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我刚刚开始阅读《应用UML和模式(第二版)》一书. 是与Modell形式的MVC等效的GRASP模式信息专家吗?

I just started to read the Applying UML and Patterns(2nd edition) book. Is one of the GRASP Patterns the Information Expert, equivalent with the Modell form MVC?

他们是否具有相同的职责(存储和检索信息)?

Do they have the same responsibilities(Storing and retrieving information)?

推荐答案

GRASP的Information Expert和MVC的Modell是否相同?

Is Information Expert from GRASP and Modell from MVC the same?

是和否

它们是否具有相同的职责(存储和检索 信息)?

Do they have the same responsibilities(Storing and retrieving information)?

不.信息专家的资格不仅限于存储和检索信息.它通常由持久层完成,我们可以将其称为纯粹的制造".

No. Information expert's eligibility is not restricted to storing and retrieving information. It is more commonly done by a persistent layer which we may call "pure fabrication".

GRASP模式(我更喜欢它们作为原则)用于确定哪个职责属于哪个班级,或者该职责是否需要新的班级.它可以帮助我们在 class级别上保持设计整洁.另一方面,MVC是关于整个系统的设计-如何划分它. MVC的3个部分通常每个都包含多个类.

GRASP patterns (I prefer them as principles) are used to determine which responsibility belongs to which class or if this responsibility necessitates a new class. It helps us keep our design tidy at the class level. On the other hand, MVC is about design of the whole system - how you divide it. Each of the 3 parts of MVC usually contains multiple classes.

首先确定建筑模式和/或设计模式.然后,我们将GRASP原则应用于系统必须执行的每个职责.

Architectural pattern and/or design pattern is decided first. Then we apply the GRASP principles for each of the responsibilities the system has to perform.

假设我们有一个应用程序,但是客户希望它具有不同的风格或UI.数据和业务逻辑是相同的.因此,MVC是使模型分离并为所有客户端重用的理想选择.

Suppose, we have an application but the clients want it in different flavours or UIs. The data and business logic are the same. So MVC is a good candidate to keep the model separate and reuse it for all clients.

现在在我们的模型中,我们有一个Customer类.该系统的一项职责是向客户发送电子邮件. Customer类存储有关客户的信息,因此是信息专家.我们将电子邮件地址存储在Customer类中,并添加方法getEmailAddress().如果我们将发送电子邮件"的职责添加到Customer类,则违反了高凝聚力".因此,我们可以应用纯粹的伪造"并添加一个新类EmailSender,该类接受电子邮件地址,主题和电子邮件正文.这个例子听起来很愚蠢,但这是我能想到的最好的例子.

Now in our model, we have a Customer class. One responsibility of the system is to send an email to the customer. Customer class stores information about the customer and so it is an information expert. We store email address in Customer class and add a method getEmailAddress(). If we add the responsibility of "sending email" to Customer class, it violates "high cohesion". So we can apply "pure fabrication" and add a new class EmailSender which takes an email address, subject and email body. This example may sound silly but that's the best I could come up with.

(在MVC架构中,模型具有控制器和视图所需的所有数据.从这个角度来看,OP认为模型是信息专家.)

(In MVC architecture, model has all the data that controller and view need. I guess, OP has thought model as the information expert from that perspective.)

这篇关于GRASP的Information Expert和MVC的Modell是否相同?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆