0

Dojo dijit 作成のベスト・プラクティスは何ですか?

  1. 純粋に宣言的なアプローチ (D)
  2. 純粋にプログラム的なアプローチ (P)
  3. 2つの組み合わせ (D&P)

基準

  1. メンテナンスが最も簡単
  2. 最速で開発
  3. 最も直感的
  4. 最高のパフォーマンス
  5. ほとんどの機能性と柔軟性

環境

Dojo を使い始めて 1 か月弱になりますが、最近、dijit ライブラリーを使い始めました。dijit のよく宣伝されている側面の 1 つは、プログラムまたは宣言によって宣言できることです。私は常に、ベスト プラクティスを理解し、特定のアプリケーションに対してどのアプローチがどのような長所/利点を持っているかについての一般的な考えを持って、新しいツール セットにアプローチすることを好みます。

以下の情報は、両方のスタイルの個人的な経験と、私が見つけた参考資料から得たもので、それほど多くはありません. このリンクは、このテーマに関する Dojo の公式ドキュメントで私が見つけた唯一のものです。この投稿では、それぞれのコードが単純なシナリオでどのように見えるかについての基本的なプレゼンテーションとともに、外部の視点を提供します。どちらのリンクも、バージョン 1.7 で AMD が導入される前の古いバージョンの dojo 用です。

プログラマティック

  1. Dojo を HTML から分離し、HTML のセマンティックの純度を維持します。
  2. イベント ハンドラーとウィジェットを同じ場所に配置して、読みやすさを向上
  3. 属性に値を動的に割り当てるのが簡単になるようです (たとえば、関数を使用して一意の ID を作成します)。

宣言的

  1. 迅速な開発 -- 直感的で暗黙的なネスト、通常の HTML 要素のように定義されたウィジェット
  2. data-jojo-* 属性の使用による有効な HTML5
  3. HTML のセマンティック純度を保持しない
  4. イベント ハンドラーは外部スクリプトから取得されるため、複雑さが増し、可読性が低下します。
  5. 最初の parseOnLoad により、事前のウィジェットのセットアップが遅くなる可能性があります

回答に関する注意事項: 回答 の各基準について説明してください。重要だと思われる追加の基準を自由に提案してください。私は決してベスト プラクティスを評価する専門家ではありません。


更新：

これに関する詳細情報を探し回った後、同様の考え方を持つ別の投稿を見つけました。これは、これらのスタイルの違いがどのような意味を持つかについての有用なコンテキストを提供します.

4

1 に答える 1

0

ベストプラクティスがないとは思いません。個人的には、プログラム コードと宣言型コードの両方を組み合わせて使用​​するのが好きです。

ビジネスロジック層からプレゼンテーション層を分離する方が理にかなっていると思います（n層アーキテクチャのように）。dijit/form/TextBoxつまり、aと標準の<input type="text" />HTML 要素の違いは何ですか? どちらもプレゼンテーション層の一部であり、同じ目的を持っています。唯一の違いは、一方がカスタム要素であり、他方がそうでないことです。

一方で、イベント処理やバリデーションはビジネスロジックと考えているので、JavaScriptに落とし込みます。オブジェクトを宣言型として宣言することもできますdojo/store。これは、私のプレゼンテーション レイヤーとは関係がないため、私も好きではありません。

さて、あなたのポイントへの対処に戻ります：

保守が最も簡単: dijit ウィジェットを変更する必要がある場合は、おそらく HTML を調べます (関心の分離、プレゼンテーション <--> ビジネス ロジック)。また、見つけやすくなっています。たとえば、dijit ウィジェットがタイトルのすぐ下、ボタンのすぐ上にあることがわかっている場合、HTML コードのどこを探すべきかが正確にわかります。プログラムで作成した場合、コードのどこにでもある可能性があります。

最速の開発: メンテナンスと開発は少し同じですが、宣言型マークアップのもう 1 つの利点は、記述したマークアップが実際にはプレースホルダーとして機能する一方で、プログラムで各プロパティを値に割り当てる必要があることです。

最も直観的: これについては、最初の部分でも説明します (最も保守が簡単です)。titleまた、 、value、placeholder、 ...などのいくつかの標準的な HTML 属性も使用していることもかなり良いと思います。これによって HTML マークアップが汚染されるとは思いませんが、可読性も向上します。

最高のパフォーマンス：それは最速の方法ではありません。私はそれをよく知っています. しかし、マージンはかなり小さいので、大きな違いというわけではありません。解析する必要があるノードを無効parseOnLoadにして手動で解析することで、微調整することもできます。もう 1 つの良い点は、エンド ユーザーが何かを「見る」ことです。たとえば、次のコードを記述したとします。

<select data-dojo-type="dijit/form/ComboBox"></select>
<input type="text" placeholder="Text..." />

ページが解析されていなくても、エンド ユーザーがページをロードすると実際に何かが表示されます (実際の結果をよく表しています)。すべてをプログラムで作成すると、ユーザーに表示されるのは白いページだけです。

ほとんどの機能性と柔軟性:宣言型とプログラム型の開発方法を組み合わせると、両方の利点を享受できると思います。宣言的な方法ですべてを行うことは多少妨げられています (すべてを HTML に入れると、イベント処理は本当に面倒に見えます) が、私はそれらを JavaScript コードで記述します。

一方で、プログラムでウィジェットを作成しているときは本当に面倒に見えるので (これは意見です)、HTML でこれらを定義する方がはるかに簡単です。

ですから、最終的には両方を組み合わせて書くのが好きです。イベント ハンドラーは確かに外部スクリプトから取得されますが、適切な MVC アプリケーションを記述した場合は常にそうなります (マークアップ自体がビューの一部であるのに対し、それはコントローラーの一部であるため)。

すべてのイベント ハンドラーを 1 つのファイルに入れる必要があると言っているわけではありません。AMD ローダーのおかげで、他のスクリプトを簡単に追加できます。特定のウィジェット (またはウィジェットのグループ) のすべての相互作用をファイルにグループ化し、これらに適切な名前を付ければ、物事を見つけるのは非常に簡単です。

ファイルが多いほど、通常、ファイルは小さくなり、読みやすくなります (そのため、複雑さが減り、読みやすさが向上します)。たくさんのファイルができあがるかもしれませんが、これらに正しい名前を付ければ (そしておそらく文書化すれば)、問題はないはずです。

しかし、結局のところ、これは意見であり、おそらく他の意見もあり、私の意見と同じか、それよりも優れています. 場合によっては状況にもよりますが、パフォーマンスが本当に最大の要件の 1 つである場合は、JavaScript ですべてを定義するのも最善の解決策かもしれません。これらのルールがどこかに石に刻まれているわけではありません。

于 2013-10-18T18:14:08.537 に答える