目前正在尝试考虑在业务层实施服务的策略。我的第一种方法是为每个类实现一个服务功能，但功能的数量最终会增长，并且很难从表示层调用，因为id必须记住它们（大量的类）。相反的替代方案是让一个单独的类实现所有服务，这将创建一个巨大的文件。
我已经看到在每个类中实现功能（方法）的实现（ProductBLL ou CompanyBLL）会使服务更易于管理，但是某些服务如“getmeProductsAndCompanies”有些频繁似乎不会既不属于ProductBLL也不属于CompanyBLL。
我的问题是：创建一个具有每个Service的方法的类AplicationService是否是一个好主意，它实例化了正确的ServiceClass和正确的方法？我的目标是在PL AplicationService中实例化as as.getmeProductsAndCompanies（）
到目前为止，我通过的互联网资料有非常理论或非常复杂的解决方案。我也愿意接受建议。
答案 0 :(得分：0)
使用composite pattern。基本上，您可以创建尽可能多的小类/函数。然后这些部分将被更大的类/函数调用。然后，更大的班级也可以被一些更大的班级再次使用。
答案 1 :(得分：0)
我的第一个方法是为每个类实现一个服务功能， 但功能的数量最终会增长并变得艰难 从表示层调用，因为id必须记住它们 （大量课程）
我不认为将所有服务聚合到一个外观中会有所帮助。它只会使它们复杂化。考虑构建服务并为它们设计一些命名模式。
例如，您有OrderService执行订单的所有操作（错误的名称选择，顺便说一下;））。最终它变得太大了，当发生这种情况时，你必须把它分成两部分。拆分时，必须使用功能方法进行命名。服务的名称必须回答问题＆＃34;该服务的确切功能以及数据类型＆＃34;。例如，OrderDisplayService对我来说是一个不错的选择。
当您必须找出需要注入哪个服务的调控器实体（通常是类似MVC的控制器）时，必须首先键入服务命名空间名称（\Acme\Services\），然后输入要处理的对象名称使用（Order），然后键入动词，描述您想要用它做什么（Display），然后按IDE自动完成按钮。你将有一个相对较短的服务列表，可用于注射（我想你使用了一些IoC容器）。
将服务拆分为多个图层或单元，以便在IDE中工作时，在当前展开的目录中只能看到功能完整的部分