Angularjs開発のいくつかの経験の総括
5699 ワード
昨年から今年にかけて,Angularjsをクライアント開発フレームワークとして用いた2つのプロジェクト開発に参加した.主にaspを利用する.Netweb apiはrestfullサービス提供フレームワークとangularjsを結合している.Angularjsはhtmlの拡張として、豊富な動的webアプリケーションを構築することを目的とし、Directiveを通じてhtml拡張のDSLモデルを構築し、PMモード変形MVVM(ネット上ではMVCモードと呼ばれることが多いが、angular 0.8は古典的なMVCモードに属すると考えているが、1.0でscopeを独立して注入した後、MVVMモードに傾いている.これは後続のエッセイに書かれている)を利用して、フロントエンドの開発を簡素化し、フロントエンドのビジネスロジックを分離させる.viewと表現ロジックの分離は、メンテナンス、拡張に便利です.AngularjsはもともとTDDを用いて開発されたもので、ユニットテストコンポーネントとEnd 2 Endのテストフレームワークを提供しています.Angularjsの強みは、WPF、Silverlightのような強力なデータバインドとフォーマットを提供し、コンポーネントをフィルタリングすることであり、MVVMモードに必要な条件でもある.さらにIOCの注入メカニズムにより,業務論理の分離ができず,サービスコードのより大きな抽象再利用が可能となった.
この節で勝手に議論するangularjs開発のいくつかの基本準則は、なぜこの勝手があるのか、angularjsに対するいくつかのプロジェクトの乱用を見たからだ.
1:すべてのページロジックを含むGodのようなpageを1つ持たないでください.
Angularjs ng-controllerは、ビジネスロジックの区分を目的としており、ビジネスロジックの区分に従ってcontrollerを区分し、ビジネス機能の高集約、controllerの単一原則SRPを実現することをより推奨しています.
2:Viewにはできるだけ少ない論理が含まれています.
jsp,aspのようなサービスエンドテンプレートエンジンのように,viewと論理の緊密な結合性をもたらすため,viewはソフトウェア開発において最も変化しやすいが,表現層論理はviewに対して相対的に安定した挙動であるため,できるだけ少ない論理をviewに置くべきである.同時に、viewの論理は自動化テストされず、継続的な統合によってカバーされず、再構築とモジュールの統合を後で修正する苦痛をもたらす.明らかにangularjsのng-switch、ng-when、ページ計算式などが多すぎる.
3:いくつかの特殊なノード式のangularjs directiveに注意して、IE 7の上でこれは認識されないため、IEの厳格なXMLモードのためです.make ie 7 happyを望むなら
1:json 2またはjson 3のjsのインポートに注意してください
2:xmlns:ngコマンド空間とノードelement式directive.
3:公式サイトで紹介されているいくつかの注意点を除いて、
またhtmlヘッダを導入することに注意(そうしないとピットパパのquirkモードに入る)
4:controllerとserviceにhtmlのDOMとCSSコードは絶対に現れない.
これは論理的なハイブリッド結合を招き、angularjs自身のバインドがhtml操作に与える場合、viewの影響源であることが分からないことが多く、バグの修復や新機能、再構築が困難になり、多くの奇妙な行為が発生します.最良の実践モデルは,必要なdom,css操作をangularのDirective,あるいはviewに移すことである.angularjsモードではdirectiveとviewのみdomとcssの論理操作が表示されます.
5:controllerで共通の論理をservice(factory,value,config)に推し進め、IOCの注入を採用し、コードの再利用度を高め、単一点、開閉原則を修正する.
6:controllerはビジネスロジックのみを含み、データモデルのフォーマットフィルタリングはangularフレームワークfilterなどの処理にできるだけ任せるべきである.
7:viewmodelでは、viewレンダリングの最小量子化modelを担持するvmなどの汎用属性を確立することが望ましい.modelの変形イベントはvm以外のscopeの上にある.これこそMVVM推奨方式です.イベントはWPFのcommandに相当し、モデルイベントの伝達によってモデルを修正し、モデルの変更からviewの強制更新を通知する(WPFのmodelはINotifyPropertyChangeインタフェースを実現しなければならない).また、vmプロパティは、データの埋め込みと収集を容易にします.
8:IOC注入優先、良好な設計、ロジックの再利用とユニットモジュールのテスト性、対象向けの「開閉原則」、修正の単一点に役立ちます.
9:良好な階層設計、viewのインタラクションに対してcontrollerを採用してviewmode(scope)のプッシュを通じて、サーバーとのインタラクションをservice階層に推し進め、angularjsの$resourceあるいは$httpを利用して更新データmodelを取得し、サービス側とインタラクションする.階層区分は縦分割に属し、同じ機能論理のインタフェースを一緒に配置し、アーキテクチャ階層を配置し、modelは業務の論理から横方向に分離する.
10:サービス側のサービスのインタフェースは表現層クライアントの応用提供を考慮する必要があり、これは良好なSOAサービス設計の準則であり、ここでは余計な説明は必要ありません.具体的にはアーキテクチャ編に進んでください.
11:もしあなたの会社が敏捷な開発を応用したら、TDDの開発は必須で、angularjsもjavascriptテスト駆動開発プロジェクトを解決します.
12:scopeの純度、scope上の各関数と属性はviewで使用する(イベント伝達または属性バインド)必要があり、使用しないものはツール関数またはserviceとして処理することができる.
13:controller間に強い依存ではなく、弱い参照であれば、イベント$emit,$on,$broadcast、はいcontroller間の低結合(Angularjs Controller間通信メカニズム)を使用することが望ましい.
14:angularjsのモジュール管理は大規模なJavaScriptアプリケーションのコードをどのように整理しますか?を参照する.
最後にangularjsも銀弾ではなく、万能ではなく、すべてのプロジェクトがアプリケーションに適しているわけではありません.CRUDのアプリケーションシステムに適しています.デフォルトのルール(慣例優先)が内蔵されています.表現層が頻繁にインタラクティブなプロジェクトには適用されません.spring hdivのような特殊なプロジェクトにもそんなに友好的ではありません.あるいは、より多くのIE 8のバージョンのアプリケーションシステムに互換性を望んでいます.同じように実用的ではありません.
この節で勝手に議論するangularjs開発のいくつかの基本準則は、なぜこの勝手があるのか、angularjsに対するいくつかのプロジェクトの乱用を見たからだ.
1:すべてのページロジックを含むGodのようなpageを1つ持たないでください.
Angularjs ng-controllerは、ビジネスロジックの区分を目的としており、ビジネスロジックの区分に従ってcontrollerを区分し、ビジネス機能の高集約、controllerの単一原則SRPを実現することをより推奨しています.
2:Viewにはできるだけ少ない論理が含まれています.
jsp,aspのようなサービスエンドテンプレートエンジンのように,viewと論理の緊密な結合性をもたらすため,viewはソフトウェア開発において最も変化しやすいが,表現層論理はviewに対して相対的に安定した挙動であるため,できるだけ少ない論理をviewに置くべきである.同時に、viewの論理は自動化テストされず、継続的な統合によってカバーされず、再構築とモジュールの統合を後で修正する苦痛をもたらす.明らかにangularjsのng-switch、ng-when、ページ計算式などが多すぎる.
3:いくつかの特殊なノード式のangularjs directiveに注意して、IE 7の上でこれは認識されないため、IEの厳格なXMLモードのためです.make ie 7 happyを望むなら
1:json 2またはjson 3のjsのインポートに注意してください
2:xmlns:ngコマンド空間とノードelement式directive.
3:公式サイトで紹介されているいくつかの注意点を除いて、
<div ng-app="xxx">
改为<div id="ng-app" ng-app="xxx">またhtmlヘッダを導入することに注意(そうしないとピットパパのquirkモードに入る)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">4:controllerとserviceにhtmlのDOMとCSSコードは絶対に現れない.
これは論理的なハイブリッド結合を招き、angularjs自身のバインドがhtml操作に与える場合、viewの影響源であることが分からないことが多く、バグの修復や新機能、再構築が困難になり、多くの奇妙な行為が発生します.最良の実践モデルは,必要なdom,css操作をangularのDirective,あるいはviewに移すことである.angularjsモードではdirectiveとviewのみdomとcssの論理操作が表示されます.
5:controllerで共通の論理をservice(factory,value,config)に推し進め、IOCの注入を採用し、コードの再利用度を高め、単一点、開閉原則を修正する.
6:controllerはビジネスロジックのみを含み、データモデルのフォーマットフィルタリングはangularフレームワークfilterなどの処理にできるだけ任せるべきである.
7:viewmodelでは、viewレンダリングの最小量子化modelを担持するvmなどの汎用属性を確立することが望ましい.modelの変形イベントはvm以外のscopeの上にある.これこそMVVM推奨方式です.イベントはWPFのcommandに相当し、モデルイベントの伝達によってモデルを修正し、モデルの変更からviewの強制更新を通知する(WPFのmodelはINotifyPropertyChangeインタフェースを実現しなければならない).また、vmプロパティは、データの埋め込みと収集を容易にします.
8:IOC注入優先、良好な設計、ロジックの再利用とユニットモジュールのテスト性、対象向けの「開閉原則」、修正の単一点に役立ちます.
9:良好な階層設計、viewのインタラクションに対してcontrollerを採用してviewmode(scope)のプッシュを通じて、サーバーとのインタラクションをservice階層に推し進め、angularjsの$resourceあるいは$httpを利用して更新データmodelを取得し、サービス側とインタラクションする.階層区分は縦分割に属し、同じ機能論理のインタフェースを一緒に配置し、アーキテクチャ階層を配置し、modelは業務の論理から横方向に分離する.
10:サービス側のサービスのインタフェースは表現層クライアントの応用提供を考慮する必要があり、これは良好なSOAサービス設計の準則であり、ここでは余計な説明は必要ありません.具体的にはアーキテクチャ編に進んでください.
11:もしあなたの会社が敏捷な開発を応用したら、TDDの開発は必須で、angularjsもjavascriptテスト駆動開発プロジェクトを解決します.
12:scopeの純度、scope上の各関数と属性はviewで使用する(イベント伝達または属性バインド)必要があり、使用しないものはツール関数またはserviceとして処理することができる.
13:controller間に強い依存ではなく、弱い参照であれば、イベント$emit,$on,$broadcast、はいcontroller間の低結合(Angularjs Controller間通信メカニズム)を使用することが望ましい.
14:angularjsのモジュール管理は大規模なJavaScriptアプリケーションのコードをどのように整理しますか?を参照する.
最後にangularjsも銀弾ではなく、万能ではなく、すべてのプロジェクトがアプリケーションに適しているわけではありません.CRUDのアプリケーションシステムに適しています.デフォルトのルール(慣例優先)が内蔵されています.表現層が頻繁にインタラクティブなプロジェクトには適用されません.spring hdivのような特殊なプロジェクトにもそんなに友好的ではありません.あるいは、より多くのIE 8のバージョンのアプリケーションシステムに互換性を望んでいます.同じように実用的ではありません.