我是如何对业务逻辑OOP的

学习PHP开发已经一年多了,从业务逻辑写到功能库再学习框架 设计,慢慢接触了一些设计模式和软件架构,总结了一些把OOP用在业务模块开发的想法。

在使用框架自带的ORM或使用独立的ORM开发业务逻辑,我基本都会抛弃ORM层,转而对DBAL层进行自己的Model类方法封装。在查询或操作数据库时Model派生类99%的操作是非常相似的,差异一般是数据表、数据库连接配置。

最初我对业务逻辑的OOP思路是将操作每张表的对象看作单独的实体,这些对象都会去继承Model,将业务模块再分割,模块内的耦合当作依赖手动注入(提前将需要用到的类全部实例化)。这种做法在结构上有些丑陋,对内存不是很友好。试想一个提供订单业务逻辑的模块,在构造时可能因为业务模块内依赖特别多,多构造了许多和自身差不多的对象(只是表名和数据库连接配置不同)当作依赖处理 …

假设我正在以上述思想设计订单业务模块

正如UML图所展示的,当业务模块被分割为众多实体,架构不清晰。即使是开发者自己维护该业务模块也将变的杂乱复杂。

后来我将业务模块设计成桥接的模式,将业务模块看作一个完整的实体。而原本模块内部细微、琐碎的方法和属性,只通过接口声明和定义赋值。并且将业务模块看作一个整体,它所操作的数据库也必然是同一数据库,数据库连接配置的声明只需要做一次即可。业务模块的所有方法实现将汇聚在一个类当中,如果使用现代化的IDE进行开发(实际上用编辑器的老司机会自己copy),比如在进行PHP开发中使用PHPStrom就会很容易的生成所有接口的方法和继承文档。

桥接模式设计的订单模块

我思考这种方式的优缺点,好处是这种方式非常适合多人环境的复杂的传统软件开发,软件架构师事先将业务模块解耦,通过接口文档的形式告诉对应的开发者实现该业务模块的逻辑,只需要实现接口中定义方法,间接的避免了开发者在业务模块之间产生内聚,每个模块都是整体、独立的。有利于功能模块代码的design和review阶段,并且有一种“万剑归宗”的美感。

缺点是设计一个业务模块要生成的文件和目录有时实在太多了,虽然在软件架构上表现的优美,但是文件太多可能也会让开发者反胃。而且一昧的“自上而下”的面向对象的软件设计,加长了设计的过程,对开发者可能会造成不小的限制,毕竟每个人的思想参差不齐。模块间不再有任何依赖和内聚,数据的统一性和正确性仍然需要一个公共的方法去维护。例如在MVC的设计架构下,通常会把这部分工作放在控制器中进行,从而导致某些控制器方法过于臃肿。又或者将模块与模块之间的协同做成数据库服务,以IoC容器的方式注册服务,但是似乎小题大做了。