数据映射器模式:在哪里放置用户模型的 checkLogin 方法?

Data Mapper pattern: where to put a checkLogin method for a User Model?

我正在尝试为用户 Class 实施数据映射器模式。

如果我理解正确,业务 class 用户不应该调用任何持久化方法,相反,它被放入数据映射器 class (UserMapper) 和映射器与数据库的接口,理想情况下使用 table 网关 class.

我有一些问题:

  1. 我应该在哪里放置 checkLogin 方法?用户还是 UserMapper?我需要通过他的 cookie 检查当前访问者的登录状态。由于用户无法引用数据库并且会话数据存储在那里我必须使用映射器 class 对吗?

  2. 验证规则放在哪里?我想把它们放在 User class 中,这样当我实例化它时,如果数据错误,我会得到一个异常。但是,对于 checkLogin() 等方法,我需要映射器上的验证规则。也许我不应该直接实例化 new User(),相反,我应该从数据映射器创建一个新用户,其中也将存储验证规则。你怎么看?

  3. 似乎这样,我最终得到了一个非常小的模型 class 和一个更大的数据映射器 class。但是由于我的大部分应用程序都是数据库交互,所以我认为这还不错。是不是代码味道?

谢谢。

我认为您在应用程序中缺少一个组件。除了 User 和 UserDataMapper 之外,您还需要另一个层来执行业务逻辑验证。我们称此为 UserBusiness。

在从 UserDataMapper 中检索到用户的详细信息后,可以在 UserBusiness 中完成 cookie/session 检查。 UserDataMapper 将 return 一个 User 对象,该对象将包含登录、sessionId 等所有详细信息。因此 UserBusiness 可以使用这些详细信息对其进行验证。

您需要在 UserBusiness 以及 User 和 UserDataMapper 中进行验证。这样做的原因是您正在验证不同的事物。 UserBusiness 中的验证规则将更加业务特定,用户名是否受应用程序规则限制(例如,大于 8 个字符可以是一个规则)。当一个字段不应该为空时,用户可以验证它是否为空。 UserDataMapper 可以验证用户名是否唯一或某些此类数据规则。您不必将验证规则限制为一个 class.

膨胀的数据层并不罕见,但如果不需要膨胀也不是一个好主意。数据层应该只处理与数据库相关的验证、检索和处理。在大多数情况下,再做任何事情都会有异味。