2

私の PHP アプリケーションは、さまざまなデータ形式 (主に XML ベース) にエクスポート (およびインポート) できる必要があります。

私には次のオプションがあります

  • PHP では、DOM を使用して、他のデータが必要とするすべてのデータのスーパーセットである XML ベースの形式にエクスポートし、サポートする出力形式ごとに個別の XSLT スタイルシートを作成し、PHP の XSL 拡張機能を介して DOM 出力を実行します。

また

  • PHP の XSL 拡張を使用するのではなく、DOM を使用して内部オブジェクト/構造から特定の XML 形式に直接変換するネイティブ PHP のクラスとして各出力形式を実装します。各クラスは同じインターフェイスを実装するため、交換可能です。

このアプリは大学で使用され、さまざまな方法で「人」の記録を管理し、人事システムなどのさまざまなソースからのインポート/エクスポートを行うツールです。入力および出力形式のセットを自分で実装しますが、将来的には、それを使用している誰かが独自のフォーマットをサポートするように変更する可能性があります。

XSLT を使用しないことを検討している理由の 1 つは、将来、私以外の誰かがアプリを保守する場合、XSLT を知っている人はほとんどいないように思われるからです。PHP を知っている人ははるかに多いようです。

もう 1 つは、2 番目の方法がより効率的で「プログラミング」ソリューションのように見え、CSV や列ベースのテキストなどの非 XML 形式に出力およびインポートできるという意味でより柔軟に、クラスの必要な部分であり、しばしば必要になるわけではありません。

3 番目の非常に小さく重要でない理由は、XSL を有効にするには PHP を再コンパイルする必要があるのに対し、DOM はデフォルトで有効になっているため、移植性が少し高くなるためです。ただし、PHP は簡単に再構成できるため、これはそれほど大きな問題ではありません。

私の推論についてどう思いますか？

4

3 に答える 3

4

私の個人的な意見は、あなたの決定は、あなたが対象とする聴衆の XSLT 知識をどのように判断するかという事実に強く基づいているべきだということです。システムを操作しなければならない人々 (あなた自身を含む) の間で、XSLT がどういうわけか「無知」であることが明らかな場合は、XSLT ソリューションを除外できます。XSLT を学習する必要性とその努力は、XSLT ソリューションから得られる利点 (特に XML を XML に変換する場合は非常に洗練されており、PHP コードをいじる必要がなく、PHP の知識も必要ありません) を無効にします。

おそらく、双方向のソリューションが適切な方法である可能性があります。XML データ形式に XSLT を使用し、XML ベースではないすべてのデータ形式に PHP コードを使用する機能を提供する、インポートおよびエクスポート用のアダプター システムを構築できます。このようにして、すべての開発者がより快適な方法を選択できます。

interface My_DataConverter_Interface
{
    /**
          * @param string                $file
          * @return My_DataObject
          */
    function import($file);

    /**
          * @param My_DataObject $data
          * @param string                $file
          */
    function export(My_DataObject $data, $file);
}

abstract class My_DataConverter_Xslt implements My_DataConverter_Interface
{ /* ... */ }

class My_DataConverter_XmlFormat1 extends My_DataConverter_Xslt
{ /* ... */ }

class My_DataConverter_XmlFormat2 extends My_DataConverter_Xslt
{ /* ... */ }

class My_DataConverter_Csv implements My_DataConverter_Interface
{ /* ... */ }
于 2009-05-04T07:08:18.513 に答える
3

あなたの推論は正しいと思いますし、それは私も同じです。

基本的に、あなたが話しているのは、ブリッジ/アダプター/ファサード クラスです。XSL テンプレートよりも (imho) 柔軟で理解しやすいものです。

3 番目の理由は、実際には 1 つではありません。XSL のサポートには、PHP 拡張機能のコメントを解除する以外に何も関係がないからです。

また、XML をテキストとして記述するのではなく、DOM 拡張機能 (または同等のライブラリ) を介してこれを行いたいと考えていることも嬉しく思います。XML をテキストとして記述すると、すべてのエスケープの問題が発生し、回避することができなくなります。

個人的には、XSL テンプレートは変更がより脆弱であると思います (大多数のプログラマーにとってはやや不可解であるという理由により)。すべてのテンプレートを変更します。もちろん、コードでもこれを行う必要があるかもしれませんが、おそらくコードの方が維持しやすいでしょう。

于 2009-05-04T03:34:49.773 に答える
2

興味深い問題です。

どちらのソリューションも機能しますが、これはご存知だと思います。

私はおそらく自分でコード化されたソリューションを使用するでしょう。しかし、それはおそらく XSLT が頭を悩ませていることに関係しています。

XSLT には利点があります。それは、変更されていない XML を提供してくれる人に作成を依頼できることです。

常にそれらを作成する場合は、おそらく問題ではなく、ほとんどの場合、コード化されたソリューションの方が保守が容易になります。

于 2009-05-04T03:51:24.400 に答える