在哪里放置不是模型而是作用于模型的类

Question

在MVC模式中，描述不完全模型的类的最佳方法是什么，但它们适用于模型？

例如，我有一个Order模型，它代表了客户在系统中的订单。我希望有一个名为Orders的类，除其他外，它将存储Order的集合并对其执行功能。我不相信这属于Models文件夹，因为它不是真正的模型。

另一个例子是用户可以导入订单，所以我会有一个Import类来处理导入。

我不相信这些是帮助类或插件，所以我不确定它们在文件夹结构方面的位置。

任何帮助表示赞赏！

编辑：只是为了描述我的Orders课程的重点 - 目前，每个Order模型都有一个validate()函数，用于检查外部WMS的库存。这个调用是非常昂贵的（一个旧的FoxPro数据库），当导入订单（你可以一次导入多个订单），而不是每个订单都有一个WMS调用，我想把这个验证功能提高1级所以我可以通过一次调用WMS系统来获得库存水平。这就是为什么我要有一个名为Orders的课程。我同意Orders实际上只是Order的集合，但我不确定现在在哪里放置此方法。正如Engineer Dollery所指出的那样，订单的关系由客户拥有（客户有很多订单），但是我觉得该功能属于客户。

Answer 1

你对一个＆＃39;模特＆＃39;是。

模型通常被认为是描述业务领域的相关对象集。在您的情况下，您有一个有订单的客户 - 可以说您的模型在客户和订单之间存在一个多关系，并且该关系本身被称为订单＆＃39;订单。如果您以这种方式查看事物，那么您描述的方法可能属于关系的所有者 - 在本例中为客户。

您可能还需要代表贵公司的所有订单，而不仅仅是一个客户。您可以通过导航（遍历所有客户并检索客户的所有订单）来实现这一目标，或者您可以建模，因为您的公司与订单有一个多关系 - 在这种情况下，您可以再次使用方法＃39;重新描述公司对象。

如果您考虑一下，只有客户或您的公司才能查看和更改订单。如果你有外在的东西＆＃39;对订单执行某些操作时，您应该了解该操作是什么，并在您的模型中表示它。每次读取或写入数据都应该通过您的模型。

修改

您提到用户可以导入订单＆＃39;并假设用户＆＃39;是＆＃39; customer＆＃39;的同义词，然后导入方法应该在客户界面上。

现在，您在编辑中谈论性能问题 - 验证方法非常慢 - 因此您希望通过同时验证多个订单来优化它。这实际上是一个实现细节，而不是接口细节（至少不在您的公共接口中）。

你指出你有一个Orders对象，这听起来不错，但这可能不应该通过你的客户界面发布（你的用户不需要知道它）。 Orders对象应该是订单集合的持有者，它应该属于客户（客户有订单） - 并且客户实现应该将validate命令委托给Orders对象，Orders对象可以以任何方式优化它。

这意味着客户不知道如何验证订单（这是有道理的），但订单（您的对象）确实如此。如果它不是您的性能约束，您可以用最简单的方式实现对订单的验证（迭代调用validate的订单），但是您确实有约束，因此您可能需要构建某种验证使用订单集合中的信息填充对象，将其传递给验证服务，并通过在各个订单上设置有效标志来对响应做出反应。

参考

我要看看这本书，实施领域驱动设计＆＃39;由Vaughn Vernon撰写，可以在amazon找到。

Answer 2

在MVC上下文中，您描述的类肯定听起来像模型。

请记住＆＃34;型号＆＃34;作为术语不限于引用单个业务对象。任何代表实现业务逻辑的操作（例如Import）的东西也都是模型。

Orders类的情况不太清楚，因为这听起来就像一个订单集合，并且不清楚为什么类本身需要在订单上执行功能（而不仅仅是允许客户端枚举订单并自己执行功能）。我会说这只是一个不恰当的例子。