XML / XSLTテクノロジーの幻想

コンピューターの世界では、特定のテクノロジーに関心が寄せられることがあります。 バーストはランダムではありませんが、これらのテクノロジーのメーカーによって明確にサポートされています。 これは驚くことではありません。同じものを売るのは難しく、新しいものや古いものを売る方が簡単ですが、名前が違うからです。 以前のモデルにはない機能よりも売れるものはありません。 なぜ消費者はそう配置されているのですか？ そして、消費者の意見はささいな搾取であり、彼は単に欲望を課した。 大規模なソフトウェアメーカーは、市場を使い果たし、更新プログラムを販売し、プログラムの価格を単純に上げるために、絶え間ない技術の変更を必要とします。 まあ、競合他社から再構築する方が簡単です。これにより、最高の最新のテクノロジーを手に入れることができます。



これがXMLで起こったことです。 結局のところ、XMLは基本的に新しいものではありません。 XMLは、IBMの1960 GMLにまでさかのぼるSGML言語の簡略化されたサブセットです。 実際、XMLは単に情報交換形式を標準化しただけです。



しかし、奇跡が起こり、XMLを入手し、広告用のオブジェクトが登場し、製造業者はすでにXMLを備えたデータベースを所有していることを隅々まで宣言し始め、一般に、すべてがXMLで飽和状態になりました。



なぜ過去を振り返ってみると、ここはAJAXであり、ここは広告と販売のオブジェクトです。 怠laな人だけが、彼がAJAXを使用しているとは言いません。



一般的に、これが世界の仕組みです。 すべての新しいテクノロジーが悪いわけではなく、敵意を持ってそれらを採用する必要はありません。 しかし、特定の決定のためのツールを選択し、ビジネスまたはビジネス上の問題を解決するためにこれらの決定を正しく行うことができる必要があります。



「アートとしてのプログラミング」という記事で、技術的なファッションに対するプログラマーの熱意について言及しました。 そして私が言ったように、私は自分自身がプログラマーであり、私と同僚が参加することは一般的でした。 この記事では、XML / XSLTテクノロジーの使用に関連する間違いについて説明します。 おそらく、この経験は誰かにとって有用であり、これらの技術を使用する適切な場所を見つけるのに役立つでしょう。 この記事は私の演説で大きな批判を引き起こすと断言できますが。



当社はいくつかのソフトウェア製品を開発しました。 しかし、最初の製品には多くの技術的およびマーケティング上の誤りが含まれていたため、市場で大きな反応は見られませんでした。



そのような製品の1つがBitrix：Info Portalです。 私たちが作成した最も洗練された製品の1つ。 MSSQLデータベースを使用したASPテクノロジーに基づいたMicrosoftプラットフォーム向けに設計され、MSプラットフォームでWebソリューションを作成するように設計されました。



この製品の最初のバージョン（1999年または2000年のようです）では、命令が正しいタグ内にあり、＃DATA（）＃のような独自の自己記述型テンプレートエンジンを作成しました。 単純な条件とサイクルがありました：さて、誰がこれを経験しなかったのですか？ はい、使用および構成のために誰かに渡されることになっていたシステムをかつて作成したすべての人が、独自のテンプレートエンジンを作成しました。



最初のプロジェクトの導入後、そのようなテンプレートエンジンに不満が生じました。 関数を追加する必要があるたびに、開発者に言語を教える必要があります。通常のデバッグおよび開発ツールはありません。まあ、一般的にはナンセンスです。 テンプレートエンジンを使用する製品にまだ出会っているとき、私はいつも驚きます。 つま先で鼻をほじるようなもので、不快で目標に到達しません。 他の人のテンプレートエンジンを使用するためのオプションがありましたが、それは石鹸に縫い付けられたものの変更でした。このオプションを受け入れず、産業用ソリューションを探しに行きました。



実際、テンプレートエンジンを作成したり、データの外観を抽象化する最良の方法は、すべてをXMLに挿入し、それをXSLTに渡してHTMLを取り出すことがプログラマーとデザイナーに教えられた多くの本と教科書です。 つまり XSLTはあなたにとって最高のテンプレートエンジンです。



XSLTテンプレートを使用するプロジェクトは、他のどのテンプレートよりもシンプルで便利である必要があり、それらを管理する方が便利であると主張されました。 そのようなプロジェクトの安全性、移植性、開発の容易さについて多くのことが言われています。



誰もが文字通りそれを受け取り、同様の製品を作り始めました。 そしてもちろん、私たちは十分に耳を傾け、私たちの未来はXML / XSLTテクノロジーであると信じていました。



彼らは偉業を成し遂げ、XSLTテンプレートを十分高速に動作させ、技術の開発に多大な労力、時間、お金を費やしました。



しかし、クライアントはルーブルで投票し、明確にした。



結果として得られたもの：



1. XSLTテンプレートの単純さの錯覚。



XML / XSLTを使用するプロジェクトは、顧客とパートナーにとってサポートするのが非常に難しいことがわかりました。 そのようなプロジェクトの所有コストは非常に高く、プロジェクトが成長するにつれて増加する傾向があります。 XSLTの専門家はほとんどいません。 技術テンプレートは、十分に高い資格の専門家によってのみ修正できます。 XPATHを使用することも、データを選択するのに特に便利ではありません。 したがって、クライアントのシンプルさとプロジェクト管理の利便性に関する幻想は払拭されました。



2.制御性と柔軟性の錯覚。



XSLTテンプレートの大部分は、サイトの公開部分に深刻なビジネスロジックを記述するのに十分ではありません。 深刻なビジネスロジックをXSLTテンプレートに移行する理由 はい、一部のアプリケーションではデータが同じであることがわかりますが、ユーザーまたはいくつかの条件に応じて、どのような形式で表示されるかが異なります。 これはテンプレートであり、ロジックが必要です。 XSLTは本格的なプログラミング言語として開発されたのではなく、単純な条件付き表現と限られたロジックのみをXSLTで作成できます。 最新のプログラミング言語とライブラリ（グラフィックス、プレゼンテーション、サービス機能など）の可能性を最大限に活用する方法はありません。



3.パフォーマンス、低コストの配置、およびスケーラビリティの錯覚。



開発者は試していないため、業界のあらゆる努力にもかかわらず、XML / XSLTシステムのパフォーマンスは非常に低いままです。 はい、このパフォーマンスを絞る方法は？ まず、SQLデータベースのデータがXMLに変換されます（これは、その構造のために大きなテキストファイルです）。 次に、XMLデータはサーバー部分に既にあるXMLパーサーにロードされます。そこでは、XPATHが動作するためにさらに多くのメモリを使用し、ロード時のXMLデータのインデックスの形成などを行います。 さらに、XSLTは膨大な量のデータを通過し、メモリを占有するテキストの出力を受け取ります。



実際のパフォーマンスソリューションはマルチレベルキャッシングでのみ表示されます。これは、開発中および使用中の両方で常に可能、望ましくない、または単に高価なわけではありません。

彼らは時々、なぜあなたはXMLで大量のデータを必要とするのかと主張します。 たとえば、XSLTなどのXMLでサイトテンプレートまたは単なるフォーラムを作成するには、ユーザー認証、統計、カタログ、製品、記事のブランチなど、ほぼすべてのデータが必要です。一部のソリューションは、XMLで必要なデータを直接管理し、 XSLT。 それでも、かなり多くのデータ、より多くの条件、より多くのメモリとクエリを抽出する必要があり、テンプレート自体はより複雑になり、実際には本格的なソフトウェアアプリケーションになり、元の目標を殺して、テンプレートを単純にします。



その結果、この技術のプロジェクトは、通常のホスティングサービスに配置するのが非常に難しく、ほとんどの場合、これらは専用のマシンです。 そのようなプロジェクトの規模を拡大する必要性はかなり急速に生じ、多大な財政的努力が必要です。



4.データと外観を抽象化する便利さの錯覚。



XML / XSLTテクノロジーを使用して誰もが追い求めている利点の1つは、外観の高品質の抽象化を実現することです。 しかし、最初のテンプレートが作成されて初めて、誰もが抽象化が判明したことを理解し、もはや誰もそれを必要としません。 XSLTテンプレートは、特に最新のAJAXアプリケーションの外観を表すために非常に複雑です。 このようなテンプレートの修正には多くの労力が必要です。 設計を完全に変更するには、すべてのテンプレートを完全に書き直す必要があります。これは、XSLTの作成の複雑さを考えると、さらに高価です。 したがって、XML / XSLTテクノロジーの所有権の価格は、開発者とその顧客の両方にとって非常に高いことがわかります。



5.ライブラリを作成できず、作業結果を再利用できない



作成されたテンプレートまたはXSLTアプリケーションをライブラリに結合して、次のテンプレートの一般的な操作の作業を簡素化することはできません。 プログラマーは、仕事を同僚に転送するのが非常に限られています。 特定されたエラーは、いくつかのテンプレートで追跡する必要があります。



6.アプリケーション開発中の開発の複雑さの非線形増加



これは本当に奇妙ですが、必要に応じて、アプリケーションを動的に開発し、スケーリングすると、XSLTを使用したアプリケーション開発の複雑さが、受信した機能に完全に不均衡になります。 アプリケーションのデバッグは困難です。 これはすべて、より多くの資格のあるプログラマーを仕事に巻き込む必要性にもつながります。



そして、技術を習得しようとする開発者の英雄的な努力の結果は何ですか？



所有と開発の大きなコスト、スケーリングの増加するコスト、製品の低需要、高価なサービス、高価な価格グループへの移行、注文数の削減、製品開発のペースの低下、稼働中のアフィリエイトネットワークの欠如...



これは、XMLを完全に放棄すべきだということですか？ もちろん違います。 XML / XSLTは非常に美しい技術であり（プログラミングフレーズですか？）、進化し続けます。 XMLは、プロジェクト（RSS、Yandex.Market、CommerceMLなど）間の通信に最適です。 小さなテンプレートとフラグメントの場合、XSLTは現在、XML処理にも非常に効果的に使用されています。



.NETは、すべてのマニフェストでXMLを完全にサポートしています。 XSLT変換もサポートされています。必要な場合-使用しますが、必要ではありません-いいえ。 しかし、XML / XSLTの使用を主張する人はいません。



最大のプロジェクトがXML / XSLTを使用する場合、非常に鮮明な例さえあります。 私の知る限り、Yandexはこの組み合わせをサービスに使用しています。 そして、私にとって、効率性の最高の結果は財政的な結果です。 議論するつもりはありませんが、Yandexの開発速度に関連する開発コストは、明らかに、このプロジェクトの許容範囲内で非常に高いと思いますが、それでも私たちが望むほど快適ではありません。 しかし、これは私の推測です。 私はYandexとの類推はしていませんが、これは不適切です。 私たちは流通製品を作りました。彼らは自分自身で内部サービスを行い、アプリケーションのすべての最適化および構成ツールを使用し、チームでのみサービスを提供することができます。



もちろん、選択したMSXMLが不良であり、新しくより優れたパーサー、より最適なプラットフォームがあると言うのは常に魅力的です。 おそらく。 しかし、これはそうではなく、問題はプロジェクトの経済学と私が上で示した理由にあります。 その結果、複製された製品でのXML / XSLTの使用は不当に高価で非実用的であるという結論に達しました。



この記事全体の目的は何ですか？ ツールを慎重に選択してください。ファッションと技術開発者の信じられないほどの効果についての保証だけに頼らないでください。 あなたが私たちのような実行製品を作っているなら、パートナーと顧客の経済を考慮してください。 製品を使用する場合、開発者はプラットフォームプログラミング言語（ASP、JAVA、PHPなど）を知っている必要があり、テンプレートとXPATHでXSLTを使用してデータを検索する必要があります。理由。



一般的に、誰も頭をキャンセルしませんでした。