我正在尝试在我的代码中更好地实现OOP和依赖注入,并遇到以下问题。
我为涉及雇主和公司的客户提供服务(使用相应的模型,地图和数据库表):
class Service
{
protected $clientId;
protected $client;
protected $employerId;
protected $employer;
protected $companyId;
protected $company;
public function setClient(Client $client)
{
$this->client = $client;
}
public function setEmployer(Employer $client)
{
$this->employer = $employer;
}
public function setCompany(Company $company)
{
$this->company = $company;
}
// more
}
要获取Service对象,我首先实例化从数据库返回clientId的Service对象。使用clientId我实例化一个Client对象(并将其附加到Service),这涉及再次访问数据库。雇主和公司也是如此。
我可以通过连接从数据库中一次检索服务,客户,雇主和公司,但这会使我的映射器更复杂。例如。客户,雇主和公司都有地址,所以我需要将这些列别名并将它们映射到相应的模型。这不仅仅是从每个表中单独检索所有列并将它们单独映射到每个模型(例如,使用一些逻辑将下划线列转换为ZF camelCase),重用我的客户端,雇主和公司映射器。
是否有最佳实践解决方案,还是取决于个人偏好和环境(性能与可维护性)?
答案 0 :(得分:1)
首先,我认为有一篇关于PHP依赖注入的伟大文章是Worth Checking Out。其次,你的问题并不是关于依赖注入的问题,因为你的主要问题是你应该多少次查询数据库。
如果您将对象注入服务中,如果您一次全部调用它们,或者一个接一个地调用它们,那么这并不重要。真正的问题只是"我能承受多次打击数据库"。 Dependency Injection的一大优点是您可以轻松更改所提供对象的源代码(因此,如果您有数据库帮助程序类或类似的东西,依赖项注入对于内部的可更改数据库对象非常有用)。
你必须在这里问自己常规的MySQL问题,以收集这些信息(性能与可维护性)。实际上,如果你有一个关系表,那么整个问题就是能够用连接查询它,并映射出那些表。
您可以查看其他ORM如何从数据库中保留其对象,但您是最了解您的应用程序的人。可维护性应该是一个巨大的问题,因为你有很好的抽象的东西。
如果您的数据库发生变化,您只需要更改映射对象,如果您的业务逻辑发生变化,您就不需要触摸您的DBAL。