yaf に基づくモジュール型開発ソリューション

ウェブサイトのトラフィックが増加し、ユーザーが増え、ニーズがますます複雑になるにつれて、製品開発期間中、ワンストップ開発ではビジネス開発のニーズをサポートできなくなります。技術的なアーキテクチャがビジネスの発展を制限しており、研究開発担当者にとっては耐えられない問題が増えています。ビジネス。

まず次のワンストップ開発が直面するであろう問題をまとめてみましょう:

1. コードの量が多く、開発、デプロイ、テストのすべてが問題になります

これは理解しやすいです、私たちのビジネス開発・導入・テストには大きなリスクが伴うことがあります。例えば、開発においては、プロジェクトに最初から参加しているメンバーであっても、事業規模が大きくなるとリスクのコントロールが困難になることがあります。大量のデプロイメントなど、ボリュームが大きいため、コードのリリースが非常に遅くなります。リリース プラットフォームでは、まずコードをパッケージ化して、オンライン サーバー上で解凍します。オンラインで問題が発生すると、ロールバックのコストが高くなり、その影響も大きくなります。リリース システムが深刻になるだけでなく、サービスの利用不能にもつながります。

2. ビジネス開発を大幅に制限する

開発者は、開発プロセス中に習慣的にパブリック関数をクラスまたはメソッドにカプセル化する傾向があり、これがコア関数である場合、システム全体に現れる可能性があります。機能の発達が必要であり、それは全身に影響を及ぼし、システムの再構築に直面する可能性があります。

非常に簡単な例を見てみましょう。

関数 (またはクラス) があるとします。

function custom_function($a,$b) {//TODO}

は、最初は現在のビジネスに合わせて基本的な機能を実装しますが、ビジネスが発展するにつれて、この基本的な機能はより強力になります。ビジネスをサポートするために、次のようなパラメータに応じて機能拡張の互換性を持たせています。後で？もちろん、私たちには聞こえませんが、それは将来の世代を非常に不幸にします。

3. 打倒と再構築を強いられる

さまざまなプレッシャーに基づいて、さらに重要なことに、事業開発のプレッシャーに基づいて、私たちはシステム全体を苦痛を伴う再構築するしかありませんでした。このプロセスは一方では長くて苦痛です。一方で、既存のシステム ビジネスをサポートしなければならない一方で、システム全体を技術的に再構築してそれらの結合を弱める必要があり、このコストとリスクが私たちを悲惨なものにします。

それでは、プロジェクトの開始時にビジネスを複数のモジュールに分割することを検討すべきでしょうか?答えは「はい」です。しかし、それはいくつかの問題ももたらします:

1. PM はテクノロジーを理解しておらず、それを分割する方法を知りません

この問題は、計画とプロジェクトのレビュー中にテクノロジーと話し合って、ビジネスに集中することで簡単に解決できます。機能を分割する。たとえば、ユーザー関連のすべての操作はユーザー モジュールに分類され、バックグラウンド関連の操作はビュー モジュールに分類されます

2. 制御の粒度が低いとコストが増加します。

これはテクノロジーに依存します 社内で十分にコミュニケーションして計画し、境界を制御します

3. データ共有?

複数のモジュールに分割されていますが、データはシステム全体に分散しています モジュール間でデータを共有するにはどうすればよいですか?

プロジェクトの初期段階での解決策は、

- 最も基本的なデータをライブラリ モジュールに分離し、モジュール全体で呼び出すことができる最も詳細なデータ共有単位を提供します。

- ビジネス インターフェイスを提供します。クロスモジュール呼び出しの場合、たとえばモジュール A の下で、フレームワークがモジュール B の下のインターフェイスの呼び出しをサポートするようにします。

- http サービス インターフェイスを提供します。これは主にプロジェクトが成熟したときに行われます。

方向性フレームワーク内にあり、次のような特徴があります:

1. コード量が少なく、合理化されている

2. モジュール間で呼び出すことができ、モジュールにはフレームワーク実装をほとんど含める必要がありません

3.基本ライブラリ モジュール

4. 管理構成

現在のすべての PHP フレームワークでは、モジュール化されたプログラミングを実現することは依然として困難です。 フレームワークの実装には、フレームワーク内に独自のアプリケーションまたはモジュールが含まれています。

一種の完全なモジュール化もあり、各モジュール ビジネスには次のような一連のフレームワーク実装があります。ただし、一方では、これの欠点は明らかです。一方、フレームワークのメンテナンスとコード量により、モジュールがより重く見えます。

つまり、最初の方法がより採用されています。今日のテーマ yaf は実際にはそのようなアーキテクチャですが、フレームワーク ロジックは so 拡張機能で実装されています

しかし、今日説明することは、この 2 つのソリューションに基づいています。モジュールを完全に独立させるだけでなく、モジュール間でインターフェイスを呼び出すこともできます。また、基本的にモジュール内でフレームワーク コードを維持する必要はありません。フレームワークの仕様に従ってコードを記述するだけです。

每个模块之间提供interface，供其他模块直接调用，每个模块只处理自己的业务，当有业务需要共享时直接按照规范写interface就可以了。

项目目录如下：

但是yaf不支持跨模块的调用，模块与模块之间是不能通过interface来通信的，为了解决这个问题，我增加了两个类Yaf_Init和Yaf_Caller

Yaf_Init

$app = Yaf_Init::init();$app->Bootstrap()->run();

这个只是一层封装，根据目录解析出当前模块名，省去配置config.ini的烦恼，为了灵活性，Yaf_init::init()后面将增加参数可以灵活自定义配置，每一个webroot/module/index.php中都是上面的代码。

等同于下面

$config = array('application'=> array('directory' => app目录))$application = new Yaf_Application($config);$application->Bootstrap()->run();

为了能够找到app的目录，还需要在php.ini中增加一个配置，

yaf.app_path = /home/admin/web/htdocs/app/

如果访问/home/admin/web/webserver/webroot/module/index.php时，

会解析出module拼成app目录：

/home/admin/web/htdocs/app/module/传给$config.application.directory，

将$config 配置传递给yaf_application的构造函数进行初始化

Yaf_Caller

$Object = new Yaf_Caller('moduleName','className');$Object->test();

这个类用来实例化其他模块中interface的类库,其实它也是一层简单的包装，保存环境变量，切换到某模块，然后调用Yaf_loader::autoload(),该构造函数接收两个参数，第一个是模块名，第二个是interface的类名，

interface的命名规范：

/app/htdocs/moduleA/Interface/Admin.php

比如模块A提供了一个interface，类名是admin

则Admin.php的类写法

class Interface_Admin{   function test(){        //TODO   }}

其他模块调用时

//object返回的是Interface_Admin类$object = new Yaf_Caller('moduleA','Admin');它直接可以调用Interface_Admin下的public方法。$object->test();

这套方案有以下优点：

－ 模块代码量小，只需要实现业务代码就可以

－ 模块之间可以无缝调用inteface接口

未完待续……

原文出处: