我正在开发一个相当复杂的物流管理系统,它将不断扩展为几个其他与ERP相关的模块。因此,我正在尽力实现SRP和Open/Close原则,以便于扩展和基于域的管理。
因此,我决定使用Laravel和以下模式(不确定是否有名称):
我将使用PRODUCT对象作为示例。 一个对象/实体/域具有一个类 class ProductService {}
这个类有一个服务提供者,包含在提供者数组中,并且也是自动加载的: ProductServiceServiceProvider 服务提供者实例化(制作)了一个接口ProductRepository。 该接口目前具有MySQL(和一些Eloquent)称为EloquentProductRepository的实现和一个ProductRepositoryServiceProvider绑定了该实现,该实现也被加载并在提供者数组中。
现在,一个产品具有许多不同的属性和与其他领域的关系,因为其他领域(或实体)需要完全分离,并再次遵守上述原则(SRP等),我决定对它们也采用与产品相同的结构……我知道有些人可能认为这太多了,但我们需要使系统非常可扩展,老实说,我喜欢有组织地统一模式(这不需要太多时间,但可以节省很多时间)。
我的问题是,处理产品所有业务逻辑并使“产品”成为它所拥有的东西的ProductService在创建实例时将注入几个依赖项。
这是它目前拥有的:
在PHP中将许多参数传递给构造函数是否是不好的实践(请忽略服务的长名称,因为当确定ERP命名空间时这些名称可能会更改)?
如Ben下面所回答的那样,在这种情况下并不是不好的实践。我的问题与OOP无关,而更多地涉及性能等等。原因是这个特定的类ProductService就像Web开发人员在控制器中所做的一样,即他们可能会(和违反原则)在一个ProductController中添加所有的DB关系,该控制器处理资源库服务(db等),并附加关系,然后它突然变成了您的业务逻辑。
在我的应用程序中(我认为大多数应用程序都是这样的),Web层只是另一层。MVC负责Web层,有时还包括其他API,但是我在我的MVC中除了与视图和JS框架相关的逻辑之外没有任何逻辑。所有这些都在我的软件中。
总之:我知道这是一个非常SOLID的设计,依赖项被注入,并且它们确实是依赖项(即产品必须具有税收,并且产品确实具有重量等),并且由于接口和ServiceProvider,它们可以轻松地与其他类交换。现在由于答案,我也知道在构造函数中注入这么多依赖项是可以的。
最终,我会写一篇关于我使用的设计模式以及为什么在不同场景下使用它们的文章,所以如果您感兴趣,请关注我。
谢谢大家
因此,我决定使用Laravel和以下模式(不确定是否有名称):
我将使用PRODUCT对象作为示例。 一个对象/实体/域具有一个类 class ProductService {}
这个类有一个服务提供者,包含在提供者数组中,并且也是自动加载的: ProductServiceServiceProvider 服务提供者实例化(制作)了一个接口ProductRepository。 该接口目前具有MySQL(和一些Eloquent)称为EloquentProductRepository的实现和一个ProductRepositoryServiceProvider绑定了该实现,该实现也被加载并在提供者数组中。
现在,一个产品具有许多不同的属性和与其他领域的关系,因为其他领域(或实体)需要完全分离,并再次遵守上述原则(SRP等),我决定对它们也采用与产品相同的结构……我知道有些人可能认为这太多了,但我们需要使系统非常可扩展,老实说,我喜欢有组织地统一模式(这不需要太多时间,但可以节省很多时间)。
我的问题是,处理产品所有业务逻辑并使“产品”成为它所拥有的东西的ProductService在创建实例时将注入几个依赖项。
这是它目前拥有的:
namespace Ecommerce\Services\Product;
use Ecommerce\Repositories\Product\ProductRepository;
use Ecommerce\Services\ShopEntity\ShopEntityDescriptionService;
use Content\Services\Entity\EntitySeoService;
use Content\Services\Entity\EntitySlugService;
use Ecommerce\Services\Tax\TaxService;
use Ecommerce\Services\Product\ProductAttributeService;
use Ecommerce\Services\Product\ProductCustomAttributeService;
use Ecommerce\Services\Product\ProductVolumeDiscountService;
use Ecommerce\Services\Product\ProductWeightAttributeService;
use Ecommerce\Services\Product\ProductDimensionAttributeService;
/**
* Class ProductService
* @package Ecommerce\Services\Product
*/
class ProductService {
/**
* @var ProductRepository
*/
protected $productRepo;
/**
* @var ShopEntityDescriptionService
*/
protected $entityDescription;
/**
* @var EntitySeoService
*/
protected $entitySeo;
/**
* @var EntitySlugService
*/
protected $entitySlug;
/**
* @var TaxService
*/
protected $tax;
/**
* @var ProductAttributeService
*/
protected $attribute;
/**
* @var ProductCustomAttributeService
*/
protected $customAttribute;
/**
* @var ProductVolumeDiscountService
*/
protected $volumeDiscount;
/**
* @var ProductDimensionAttributeService
*/
protected $dimension;
/**
* @var ProductWeightAttributeService
*/
protected $weight;
/**
* @var int
*/
protected $entityType = 3;
public function __construct(ProductRepository $productRepo, ShopEntityDescriptionService $entityDescription, EntitySeoService $entitySeo, EntitySlugService $entitySlug, TaxService $tax, ProductAttributeService $attribute, ProductCustomAttributeService $customAttribute, ProductVolumeDiscountService $volumeDiscount, ProductDimensionAttributeService $dimension, ProductWeightAttributeService $weight)
{
$this->productRepo = $productRepo;
$this->entityDescription = $entityDescription;
$this->entitySeo = $entitySeo;
$this->entitySlug = $entitySlug;
$this->tax = $tax;
$this->attribute = $attribute;
$this->customAttribute = $customAttribute;
$this->volumeDiscount = $volumeDiscount;
$this->dimension = $dimension;
$this->weight = $weight;
}
`
在PHP中将许多参数传递给构造函数是否是不好的实践(请忽略服务的长名称,因为当确定ERP命名空间时这些名称可能会更改)?
如Ben下面所回答的那样,在这种情况下并不是不好的实践。我的问题与OOP无关,而更多地涉及性能等等。原因是这个特定的类ProductService就像Web开发人员在控制器中所做的一样,即他们可能会(和违反原则)在一个ProductController中添加所有的DB关系,该控制器处理资源库服务(db等),并附加关系,然后它突然变成了您的业务逻辑。
在我的应用程序中(我认为大多数应用程序都是这样的),Web层只是另一层。MVC负责Web层,有时还包括其他API,但是我在我的MVC中除了与视图和JS框架相关的逻辑之外没有任何逻辑。所有这些都在我的软件中。
总之:我知道这是一个非常SOLID的设计,依赖项被注入,并且它们确实是依赖项(即产品必须具有税收,并且产品确实具有重量等),并且由于接口和ServiceProvider,它们可以轻松地与其他类交换。现在由于答案,我也知道在构造函数中注入这么多依赖项是可以的。
最终,我会写一篇关于我使用的设计模式以及为什么在不同场景下使用它们的文章,所以如果您感兴趣,请关注我。
谢谢大家