实体和服务作为MVC设计模式的分布式逻辑基础

在开发不同规模的应用程序时，采用不同的方法来设计Web应用程序变得越来越有趣。最近，基于MVC设计模式的大型项目中的逻辑分离问题变得尤为突出。

实体和服务

实体

由于任务变得越来越复杂，并且不可能将所有数据存储在数据库中，因此决定在项目中创建静态数据实体。本质很简单-在某个地方存储了基本静态数据，可以用PHP代码对其进行操作，并将其英语表示形式输入数据库。



在基本视图中，Entity.php类可能如下所示：

declare(strict_types = 1);

namespace entities;

class Entity {
	protected static $map;
	
	public static function getMap():array {
		return static::$map;
	}
}

其继承人必须实现$ map属性，他们将获得以下内容：

E1::getMap();

而且，大多数静态数据将满足接收逻辑。如果需要对数据进行分组或选择其他数据，则该逻辑已在继承的类中实现。

服务

服务旨在存储应用程序的业务逻辑。此外，服务可以用作与框架分离的逻辑。服务是实现应用程序逻辑的方法的集合。为服务定义的条件：

• 服务不应独立访问控制器和视图；
• 服务可以访问数据库，模型和实体。

在最佳情况下，控制器必须将所有必要的数据传输到服务，但是可能会出现这样的情况，即它需要独立地引用某种模型来获取数据。这样做没有错，但是最好遵循控制器操作数据路由的逻辑。



默认情况下，该服务不实现任何标准逻辑，因为它是项目一部分的唯一执行。因此，决定不创建基本服务类。但是，应注意，即使基类为空，也最好创建它们。这是由于以下事实：所有继承人都需要具有相同的逻辑或执行某种方法的时刻到来。为了不对所有类进行继承更改，从基类进行初始继承比较容易，在这种情况下，就临时资源而言，这种情况要简单得多且便宜得多。



一般而言，所提出的体系结构中的数据流可以表示如下：

1. 数据或请求将发送到控制器。
2. 控制器以双向方式与模型，服务和实体进行通信。他在这里接收并返回一些数据。
3. 该服务将数据发送到控制器，接收数据或将数据发送到模型。
4. 控制器将接收到的数据发送到视图。

因此，事实证明，应用程序的数据和操作原理分布在基本MVC元素和新元素之间。

结论

值得注意的是，这种方法的引入使得可以显着简化应用程序的开发并控制数据流。大多数数据都从数据库中取出，从而减少了请求的数量，从而减小了数据库的大小并提高了应用程序的整体速度。