PureMVC フレームワークの宣言された目標の 1 つは、移植可能にするためにプラットフォームの依存関係を回避することです。言語と API の違いにより、アプリケーション コードは常にプラットフォームに大きく依存し、プラットフォームの依存関係を回避すると、フレームワークが車輪を再発明したり、最小公分母の機能セットのみを提供したりすることを考慮すると、どのように移植性が向上しますか?フレームワークの利点は、アプリケーション開発者としての私ですか?
6 に答える
PureMVCを使用しました。彼らは自分たちのものをかなり多くの言語で実装しようとしています。あなたは最小公分母について正しいかもしれませんが、全体として、それは悪いフレームワークではありません、そして私はPureMVCで本当に素晴らしいAS3アプリを見ました。
実際のコードを移植するという観点から、移植性について話しているとは思いません。他のプロジェクトや他の言語に適用できる、一般化されたMVCアーキテクチャを使用しているという考えがあります。
彼らは、PureMVCパターンに精通していれば、たとえそれが別の言語であっても、新しいPureMVCコードベースに入る可能性があり、その土地の産地をすでに知っているだろうと言っています。
また、優れたPureMVCスキルを開発する開発者は、言語から言語へと移行するときに翻訳される優れた習慣を身に付ける可能性が高いと言うかもしれません。しかし、繰り返しになりますが、おそらくそうではありません。あなたが言及した理由のためです。
PureMVC の移植性は、別の言語に移行または再実装するときに役立ちます。
私がコードを書いたプラットフォームや言語の数は数え切れません。それらのコードは現在絶滅しており、ソースコードがまだあったとしても、ほとんど価値がなく、今日ゼロから書き直さなければなりません。コードは通常、100% プラットフォーム固有のものでした。
ただし、すべてのアプリケーション コードがプラットフォームに大きく依存している必要はありません。ビュー コンポーネントとサービス (アプリケーションの境界) は必ず存在しますが、境界に挟まれたアプリケーション ロジックはそうである必要はありません。
PureMVC の適用範囲は非常に狭いです。MVC メタパターンによって禁止されている 3 つの層にコードを分割するのに役立つだけです。最適化するために、このコードをプラットフォームに深く結び付けなければならない理由はありません。
移行の時期になると、フレームワークのアクターとその役割、責任、およびコラボレーションが同じままであることを理解するでしょう。これにより、言語の構文の違いに対処し、ビュー コンポーネントとサービスを再作成する必要があります。少なくとも、完全に再設計する必要はありません。
また、別の言語で再実装する場合、アプリでモバイル市場の大部分を獲得しようとしていると想像してください。市場は非常に細分化されているため、2 つ以上の Windows Mobile、iPhone、Flash、および Java に同じプログラムを実装する必要があります。確かに、アプリケーションを担当する別のチームが存在することになるでしょうが、まったく異なるアーキテクチャを使用するのはなぜでしょうか? PureMVC を使用すると、アプリケーションのすべてのバージョンに対して単一のアーキテクチャを持つことができます。
-=クリフ>
現在、2 つのプロジェクトで PureMVC を使用していますが、私の意見では、言語に依存しないようにすることはかなりの負担です。
フレームワークがすでに知っているので、プロジェクトに直接ジャンプするという約束は、言語がまだかなり似ていない場合、私には関係がないように思えます (C# から Java へは意味があり、as3 から php へはそうではありません)。物事を解決する既知の方法がありますが、そのためには「単純な」パターンで十分です。
しかし、私はプロジェクトが使用するさまざまなパターンの使用法にもあまり同意しません。そのため、次のプロジェクトでそれを使用しないという私たちの選択は、言語/プラットフォームの独立性の試みだけでなく、両方の問題に関連している可能性があります.
Flex Framework を使用しないことを選択した Flash Platform 開発者にとって、PureMVC は唯一の現実的なオプションです。特定のプロジェクトでは、Flex のサイズ コストが高すぎます (実際に起こります!)。
私は、Flex でプロトタイプを作成し、アプリケーションが完成間近になったら、それを切り取ってビューをカスタム コンポーネントに置き換えるのが好きです。PureMVC では、Mediator パターンを使用してこれを非常に簡単に行うことができます。このワークフローを可能にする他のフレームワークがあるかどうかはわかりません。
個人的には、PureMVC は移植性の目標を達成しすぎたと思います。(上記の理由により) Flash と Flex で動作するという事実を楽しんでいますが、そこで止めて、ネイティブの Flash Player イベントを利用するべきだったと感じています。建築。
PureMVCを使用して複数のプラットフォーム間でアプリケーションを構築および移植する人々の例はありますか?
私の会社は、他のプラットフォームに移植する必要があるかもしれないFlexアプリケーションを構築しています。
- Silverlight(可能性が高い)
- モバイル(たぶん)
- デスクトップ(たぶん-AIRだけではありません!)
- テレビ(多分最終的に)
PureMVCが移植と保守を容易にすることができれば、フレームワークとして検討しています。他の人がPureMVCアプリを別のプラットフォームに移植したかどうか、そして移植してから複数のプラットフォームでアプリの開発を並行して進めた経験を知りたいです。
乾杯、
Karthik
PureMVCは、内部動作(Flashイベントなど)をプラットフォームに依存していません。したがって、移植を簡単にすることはできませんが、どこに行っても親しみやすく親しみやすい顔を見せることで簡単に支援できます;-)