Lisk Research – LIP-11の概要

ここに、Lisk Researchに関する別のLIPの新しい記事があります。今回は、LIP-5で説明されているデータベースコンポーネントにExtended Data Mapper(拡張データマッパー)パターンを使用することを提案するLIP-11を扱います。

LIP-11の作成者は、Oliver BeddowsとAndreas Kendziorraのサポートを受けたNazar Hussainです。彼らは、Lisk Coreの永続化レイヤーを拡張および維持するのに役立つ、普遍的で理解しやすい構造化モデルを提案します。

開発者は、現在のLisk Coreモデルでは、データの永続性を担うロジックがコードのさまざまな部分に不規則に広まっていると説明しました。そのような配布は、同等の機能のための余分なインターフェイスが存在することを意味し、これによりコードを長期にわたって維持および拡張することが困難になります。さらに、これらすべてのインターフェース間で統一された設計はないため、どのモジュールでどのインターフェースを使用するかを決定することは困難です。

現在のLisk Core実装のロジック分布を上の図に示します。重複のために、適切なインターフェイスを選択する際の前述の困難に気付くことができます。また、この写真は、たとえば、データベースからアカウントを取得するために使用可能ないくつかのインターフェースがあることも示しています。さらに、インターフェースは現在、Lisk Coreで使用されているデータベースソリューションであるPostgreSQL RDBMSと強力にリンクされています。

LIP-5（この記事で説明）は、永続レイヤーからデータを取得する目的で、すべてのモジュール間でインターフェイスを共有することを意味します。これは、どのネームスペースをモジュール間で共有するかを決定することが難しい複雑な状況に移行します。開発者によって提案されたモデルは、LIP-5の要件を満たす永続ロジックの明確な抽象化レイヤーによってこの問題に直面しています。

新しい設計パターンは、次のように特徴付けられる必要があります。

1. システムを介したデータベース同等のコードエンティティのマップ。
2. 新しい特殊なエンティティを作成するために、エンティティを広げる簡単な方法を提供します。
3. 複数のデータベーステーブルにわたるエンティティ属性のマッピングをサポートします。
4. インターフェイスおよび外部モジュールの公開された読み取り専用インスタンスへのアクセス制限を許可することにより、データアクセスレイヤーを保護します。
5. 他のモジュールがモジュール固有のエンティティにアクセスできないように、エンティティの実装を分離します。

開発者は、前述のニーズを満たすことができるソフトウェア業界で使用される3つの設計パターンを提案します。

1. アクティブレコード：中規模のプロジェクトに適していますが、数百万のデータオブジェクトがあるLiskの場合には適していません。さらに、このパターンは、複数のデータベーステーブル間でエンティティ属性をマッピングする要件を満たしていないため、実装できません。
2. データマッパー：パフォーマンスを向上させるためにネイティブJSONオブジェクトに基づいており、JSONからデータベースへの双方向のシリアル化をサポートしています。また、複数のデータベーステーブルにまたがるエンティティ属性のマッピングもサポートしていますが、すべてのエンティティにCRUDインターフェイスのみを持つように制限されています。
3. リポジトリ：その柔軟性により、さまざまな方法で実装できます。ただし、標準やガイドラインがないため、インターフェイスや動作全体に一貫性を実装するために使用することはできません。

結論として、開発者によって提案されたソリューションは、標準のCRUD操作と柔軟なインターフェイスの両方をサポートするために、データマッパーパターンとリポジトリパターンの結合にあります。新しいパターンには「Extended Data Mapper(拡張データマッパー)」という名前が付けられ、そのアーキテクチャを説明する図を以下に示します。

トピックについて詳しく知りたい場合は、GitHubのLIPページで各LIPの説明を読むことができます。

_________________________________

Lisk MagazineはLisk Italian GroupとEliteXによってサポートされているプロジェクトです。
私達の仕事をサポートし、Lisk Magazineに投票してください。

この記事はLisk Japanによって翻訳されました。