实施3结构模型(域对象，数据映射器和服务)时存在一些不确定性 [英] Some uncertainty with implementing the 3 structure Model (Domain object, data mapper and service)

问题描述

正如标题所示，在实现3结构模型(域对象，数据映射器和服务)时，我遇到了一些小问题.

As the heading suggests I am having some small problems while implementing the 3 structure Model (Domain object, data mapper and service).

过去，当有人在我的网站上注册时，我会简单地做

In the past when someone was registering on my site I would simply do

$user->register($firstName, $lastName, $emailAddress, $username...);

并且该方法将按以下步骤运行

and that method would run in steps like this

1. Check if the form sent was valid.
2. Check if all the required fields were filled.
3. Check the if the lengths of strings were valid and the range of integers etc.
4. Check if the input is in the correct format (regex).
5. Check if the username is already taken and if the email address already exists
   in the database
6. etc. etc.

一切正常，但我想摆脱这种方式，因为我希望我的代码更具可重用性和可测试性.

All that works fine but I'm trying to get away from doing it that way because I want my code to be more reusable and testable.

现在，使用这种3结构模型，域对象和数据映射器应该通过服务进行通信，以使它们彼此隔离，所以这是我对用户服务的想法

Now, with this 3 structure Model the Domain Object and the Data Mapper are supposed to communicate through a Service to keep them isolated from one another so here's my idea of a User service

class UserService {

    public function register($firstName, $lastName, $email...) {

        $userDO= $this->domainObjectFactory->build('User');
        $mapper  = $this->dataMapperFactory->build('User');

        // Is this where I start doing my validation like in the steps above???
        // And if this is where I start doing my checks, when I get to the part
        // where I have to check if the username they want is already taken how
        // how do I do that check?

    }    

}

然后要实际运行，我将像这样从控制器中进行操作

And then to actually run that I would do it from my controller like so

$userService = $this->serviceFactory->get('user');
$result = $userService->register($_POST['firstName']....);

逻辑(如果是，否则为逻辑)必须放在我的UserService类的register()方法中，对吗?因为当我到达需要数据库进行某些检查(例如用户名是否已存在)的阶段时，如果它们进入域对象，我将如何访问数据库?我真的不知道，因为域对象不应该对数据源一无所知.

The logic (if's and else's) must go in the register() method in my UserService class right? Because if they go in the Domain Object when I reach the stage of needing the database to do some checks like if the username already exists how would I access the database? I really don't know since the domain object is not supposed to know anything about a data source.

对于小查询，必须有一种访问数据库的方法，例如检查用户名或电子邮件地址是否已存在以及是否需要加载其他小查询.

There has got to be a way to access the database for small queries like checking if a username or email address already exist and loads of other little queries that need to be done.

我有很多实体/域对象，它们需要执行少量查询，并且过去我的模型可以从任何方法内访问数据库，并且可以执行这些查询，但这似乎不被允许3结构模型，我渴望找到正确的方法，因为必须有一种方法.

I have lots of entities/domain objects that need to do loads of little queries and in the past my model had access to the database from within any method and could do those queries but that doesn't seem to be permitted with this 3 structure model and I'm dying to find out what is the correct way to do it because there has to be a way.

我一直在飞行它，直到我发现一个模型是被分成3个结构的层.

I was flying it until I found out a Model is a layer which is broken into 3 structures.

我们将不胜感激任何帮助或朝着正确的方向前进，特别是在现实生活中的例子.互联网似乎缺少针对我的特定问题的那些内容.

Any help or push in the right direction would be greatly appreciated, especially good real life examples. The internet seems to be lacking those for my specific problem.

谢谢.

推荐答案

我正在经历与您现在相同的事情(对于这个确切的问题，这很有趣-用户注册/授权).

I am going through the same thing you are right now (funny enough, for this exact problem - user registration/authorization).

我的一项建议是，您不应将模型限制为仅3层(在这种情况下为3个类).一个模型应具有所需的多个类，以便在保持SRP(单一职责原则)完整性的同时完成工作.

One piece of advice that I have is that you should not restrict your model to just 3 layers (in this case, 3 classes). A model should be as many classes as needed in order to get the job done while maintaining SRP (single responsibility principle) integrity.

例如，您可能还想使用UserTableGateway类来补充UserDataMapper，并使用UserCollection类来允许潜在的分页功能或常规用户列表.所有这些都可能是您的模型和UserService层的一部分.

For example, you might also want to use a UserTableGateway class to compliment the UserDataMapper, and a UserCollection class to allow for potential pagination functionality or general lists of users. All of those things could be part of your model and UserService layer.

要回答有关注册过程特定逻辑的问题，是的，最合适的位置是UserService类的register方法.

To answer your question about the logic specific to the registration process, yes, the most appropriate place for it is in the register methods of the UserService class.

所有这些，您可能想在这里考虑您的域结构. UserService是最合适的注册场所(通过扩展名，登录名，恢复密码，更改密码等)吗?

All that said, you might want to think about your domain structure here. Is a UserService the most appropriate place for registration (and by extension, login, recover password, change password etc)?

也许这些东西可能是与帐户相关的完全不同的模型的一部分.服务类可能是这样的:

Perhaps those things could be part of a totally different model related to Accounts. A service class could be something like this:

class Account 
{
    // Think of this as AccountService, it will have a number of collaborators,
    // including an Authenticator class for loggin in, a Session class for managing the session
    // and of course various persistence classes for storing the user, session and credentials


    public function register(UserInterface $user) {}
    public function login($email, $password) {}
    public function logout(UserInterface $user, $session_id) {}
    public function changePassword($user_id, $old_password, $new_password) {}
    public function recoverPassword($user_id, $email) {}
}

鉴于UserService可能负责许多其他事情，因此将与用户帐户相关的所有内容保留在其自己的服务类中是很有意义的.

Given there are potentially dozens of other things a UserService could be responsible for, it makes sense for you to keep everything related to the user's account in its own service class.

从概念上讲，帐户与用户始终是不同的，并且如果在概念上不同，则应拥有自己的类.

Conceptually, an account is different from a user anyway, and if it's conceptually different, it deserves its own class.

现在，就让Account服务类获得所需的依赖关系而言，在我对复杂系统设计的理解这一阶段，这已经超出了我的范围.

Now, as far as getting the Account service class the dependencies it needs, that's beyond me at this stage in my understanding of complex system design.

这篇关于实施3结构模型(域对象，数据映射器和服务)时存在一些不确定性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！