2

この質問が、最初に思われるほど広範に出てこないことを願っています。<sarcasm>膨大な</sarcasm>空き時間にソフトウェア アプリケーションを設計しています。クロスプラットフォームとモジュラーの両方を実現したいと考えています。現時点では、まだ計画段階にあるため、実質的に任意の言語とツールセットを選択できます。

両方の目標 (モジュール性、プラットフォームにとらわれない) を達成する方法が非常に多いように見えるため、これは物事を容易にするのではなく、困難にします。

私の基本的な前提は、セキュリティ、データ ストレージ、オペレーティング システムとの対話、および構成はすべて「コンテナー」アプリケーションによって処理される必要があるということですが、その他の機能のほとんどはプラグイン モジュールを通じて提供されます。大まかに説明する必要がある場合 (私のアイデアを完全に放棄することなく)、それは多くの異なるジョブを実行できる単一のアプリケーションであり、すべてが同じ目標に専念しています (実行すべきさまざまなことがたくさんありますが、すべてのデータは相互に作用し、可用性が高くなければなりません)。

これは新しいアイデアではなく、特に風変わりなものでもありません。それでも、どのようにそれを行うかということではなく (多くの方法を考えることができます)、どの方法が最適かということで苦労していることに気づきます。

たとえば、私が説明していることを Eclipse が実際に体現していることはわかっていますが、一般的に Java アプリケーション (Eclipse も例外ではありません) は、私が必要とするものに対して大きすぎて遅すぎると感じています。同様に、Python と Ruby で記述されたデスクトップ アプリ (これらは優れた言語です!)

さまざまなプラットフォーム用にコード ベースをネイティブ実行可能ファイルとして再コンパイルすることは気にしません。しかし、C と C++ にはそれぞれ独自の問題があります。

C# 開発者として、私はマネージ コードを好みます。しかし、私はまだ、Mono をまったく気に入っていません (確信できました)。

共有するアイデア/経験/特定のお気に入りのフレームワークを持っている人はいますか?

4

6 に答える 6

1

デスクトップまたは Web アプリケーションを計画していますか?

ここら辺の誰もが Mono は素晴らしいと思っているようですが、私はまだそれが産業で使用できる状態にあるとは思っていません。それが機能するときはうまく機能し、機能しないときは...うまくいきません。Apache の mod_mono は非常にグリッチが多く、正しく実行するのは困難です。

デスクトップを目指すなら、Eclipse RCP (Rich Client Platform) フレームワークに勝るものはありません: http://wiki.eclipse.org/index.php/Rich_Client_Platform。

ウィンドウ、Linux、Mac をすべて同じコードでビルドでき、すべての UI コンポーネントは OS にネイティブです。そして、RCP はモジュール性で勝っており、他の追随を許さないプラグイン アーキテクチャを備えています (私が見た限り)。

私は RCP を 1.5 年間使用してきましたが、他に何が置き換えられるかはわかりません。これはニッチ市場で 1 位です。

あなたがJavaに完全に反対しているなら、私はpythonまたはC ++のいずれかでwxWidgetsを調べます

于 2008-08-28T22:34:48.753 に答える
1

例を挙げると、.NET アプリの場合、CAB (複合アプリケーション ブロック) と WPF の複合アプリケーション ガイダンスがあります。どちらも主に、モジュール性とプラグイン アーキテクチャに似たコンポーネント間の疎結合に焦点を当てたいくつかの設計パターンのセットの実装です。IOC フレームワーク、MVC 基本クラス、疎結合のイベント ブローカー、モジュールの動的読み込みなどがあります。 .

したがって、.NET に特化したものではなく、そのようなパターン インフラストラクチャを見つけようとしていると思います。しかし、CAB を一連のパターン実装と見なすと、ほぼすべての言語とプラットフォームに、個々のパターン用の何らかの形式の組み込みフレームワークまたはサード パーティ フレームワークがあることがわかります。

したがって、私の見解は次のようになります。

  1. これらの設計パターンのいくつかを (よく知らない場合は) 調べてください。例として、WPF ドキュメントの CAB フレームワークを取り上げることができます:複合アプリケーション ライブラリのパターン
  2. 特定のパターンの実装や製品を考えずに、最初に達成したいことに対してどのパターンが役立つと思うかを考えてアーキテクチャを設計してください。
  3. 「アーキテクチャ要件」をより具体的に定義したら、使用する言語のパターン/機能のそれぞれを達成するのに役立つ個々のフレームワークを探し、それらに基づいて独自のアプリケーション フレームワークを作成します。

このプラットフォームをすべて独立させるのが難しい部分であることには同意します。Java のような成熟したプラットフォームに依存しない言語を選択するための他のソリューションは考えられません。

于 2008-08-28T22:45:33.983 に答える
1

プラットフォームの独立性が必要な場合は、パフォーマンスと開発作業の間でトレードオフを行う必要があります。C++ は Java よりも高速かもしれませんが (これは FWIW で議論の余地があります)、Java を使用すると、プラットフォームの独立性をはるかに容易に得ることができます。Python と Ruby は同じ船に乗っています。

.NET が Java よりもはるかに高速であるとは思えませんが (どちらも VM 言語なので)、.NET の大きな問題はプラットフォームの非依存性です。Mono には崇高な目標があり、これまでのところ驚くほど良い結果が得られていますが、常にWindows で Microsoft に追いつくことになります。その制限を受け入れることはできるかもしれませんが、Java、Python、および Ruby が持つ同一のマルチプラットフォーム環境を持つことと同じではありません。また、.NET 開発およびサポート ツールは Windows に大きく偏っており、おそらく常にそうなるでしょう。

IMO、あなたの最善の策は、Javaをターゲットにすることです...または、少なくともJVMです。Java 言語が気に入らない場合 (C# 開発者としては、そうではないと思います)、少なくとも Jython、JRuby、Scala などのオプションがあります。JVM を使用すると、非常に優れたプラットフォーム非依存性、優れたパフォーマンス、および膨大な数のライブラリとサポート ツールへのアクセスが得られます。ほとんどの場合、必要なことを実行する Java ライブラリ、ポート、または実装が存在します。他のどのプラットフォームにも同じ数のオプションがあるとは思いません。その柔軟性には真の価値があります。

モジュール性については、どのプラットフォームを使用するかよりも、ソフトウェアをどのように構築するかが重要です。あなたが説明したようなプラグイン アーキテクチャについてはよくわかりませんが、あなたが選択したほとんどすべての最新のプラットフォームで可能になると思います。

于 2008-08-28T22:51:31.397 に答える
1

Python での開発を計画している場合は、いつでもpyrexを使用して遅い部分を最適化できます。

于 2008-08-28T22:55:07.003 に答える
0

デスクトップ アプリケーションの場合は、インタプリタ言語で記述し、wxWidgets のようなクロスプラットフォーム UI ツールキットを使用すると、プラットフォームの独立性に向けて長い道のりを歩むことができます (クロスプラットフォームではない他のモジュールを使用しないように注意する必要があります)。 、のようなことをする代わりに、Pythonのos.pathモジュールのようなものを使用してくださいconfig_path = "/home/$USER"）

とはいえ、優れたクロスプラットフォーム アプリケーションを作成するには、プラットフォームごとにいくつかのことを異なる方法で行う必要があります。

たとえば、OS X はおそらく最も異なるものです。設定は通常 ~/Library/Prefernces/ に .plists として保存されます。UI は通常、フローティング ウィンドウに基づいており、単一のメニューバーが画面の上部にドッキングされています。

ここでモジュール性が発揮されると思います.上記の設定の例では、UserConfigOS 固有のバージョンを持つ class を持つことができます。Windows の場合、構成データは適切なApplication Dataフォルダーまたはレジストリに保存されます。Mac OS のものは .plist ファイルを使用し~/Library/Preferences/、unix のものは ~/.dotfiles を使用します。

于 2008-10-10T07:40:13.933 に答える
0

限られた Mono の経験で、私はそれでかなり売れたと言えます。開発が活発に行われており、最新の .Net テクノロジを使用して仕様に合わせるための多くの継続的な努力が行われているという事実は、心強いものです。複数のプラットフォームで既存の .Net スキルを使用できることは非常に便利です。Python + PyGTK でいくつかの基本的なタスクを実行しようとしたときに、パフォーマンスに関して同様の問題が発生しました。おそらく、それらは正しい手で実行できるようにすることができますが、90% の確率でパフォーマンスを心配する必要がないのは素晴らしいことです。

于 2008-08-28T22:08:02.640 に答える