5

MonoTouch と Mono For Android プロジェクトの間でビジネス ロジックの C# コードを共有するためのベスト プラクティスは何でしょうか?

編集済み: 最初に、私の質問は物理的なファイル共有に関するものでした:

  1. 何を使用することを提案しますか: ネットワーク ファイル共有または何らかのコード バージョン管理 (git、svn)? 私の場合、Mac (MonoDevelop with MonoTouch) と PC (Visual Studio with MonoDroid) の 2 つのワークステーションを使用しています。
  2. ソリューション/プロジェクトのフォルダー構造はどうですか? 「ブログ投稿: Xamarin Mobile World Congress 2012 Unofficial Conference App Released!」では、構造の例が非常に紛らわしく、1 つのフォルダーに複数のソリューションがあり、1 つのサブフォルダーに異なるフォルダーとプロジェクト名を持つ異なるプラットフォーム プロジェクトが含まれています。IDE でネイティブに実現することはできません。ソリューション ファイルの内容とフォルダ名を IDE 環境外で手動で編集していますか?
  3. また、共通コードのプロジェクトでは、どのようなプロファイル (テンプレート) を使用すればよいでしょうか? Monotouch にはいくつかあります: 空のプロジェクト、MonoTouch ライブラリ プロジェクト、MonoTouch バインディング プロジェクト? Androidでは、Androidクラスライブラリだと思いますか?
4

2 に答える 2

12

これは非常に一般的な質問ですが、始めるのに役立つリソースがいくつかあります。

  1. ビデオ:クロスプラットフォーム モバイル開発
  2. ブログ投稿: Windows Phone 7、MonoDroid 以降の共有ライブラリ
  3. 書籍: C# を使用したモバイル開発
  4. ブログ投稿: Xamarin Mobile World Congress 2012 非公式カンファレンス アプリがリリースされました!

編集 (新しい質問に回答するため)

  1. プロジェクト間でファイルをリンクする背後にある考え方は、ファイルの実際のコピーは 1 つだけであり、複数のコピーを自分で管理して同期を保つ必要がないということです。ファイルは実際には 1 つのプロジェクトにのみ存在し、他のプロジェクトにリンクされますが、プロジェクトがコンパイルされると、ファイルが実際に存在するかのように扱われます。

  2. 彼らがフォルダー構造をどのように作成したかを正確に話すことはできませんが、必要なものを取得する方法がなかったため、プロジェクトまたはソリューション ファイルを手動で編集して、必要なフォルダー構造を取得するケースが多かったことは知っています。 IDE のみ。これは、フォルダをどのように構造化するかについての個人的な好みに帰着します。

  3. 最終的に必要なのは、対象とするすべてのプラットフォーム用のクラス ライブラリ プロジェクトです。リンクされたファイルのアプローチを使用する場合、物理ファイルをどこに置くかは完全にあなた次第です。私がよく使用する 1 つの方法は、実際に標準の .NET 4.0 クラス ライブラリを作成し、そこにファイルを配置してから、それらを Mono for Android および MonoTouch クラス ライブラリにリンクすることです。iOS と Android をターゲットにすることだけを考えている場合、それは価値があるよりも面倒なことになる可能性があり、ファイルを 1 つのプロジェクトに置いて、別のプロジェクトにリンクすることができます。

于 2012-05-18T16:46:00.497 に答える
8

免責事項:私は、マルチプラットフォーム プロジェクト間でコードを共有するために使用する特定の Mvvm 方法論を持っています...

それにもかかわらず、私は「フリーサイズ」のフレームワークを心から信じていません。プロジェクト、開発者、および組織に最適なアプローチを慎重に選択する必要があると思います。

そうは言っても、Mono 開発アプローチ内で使用できるツールの一部は次のとおりです。

  • ポータブル クラス ライブラリを使用して、プラットフォーム間でまったく同じコードを共有する
  • プラットフォーム固有のクラス ライブラリを使用してプラットフォーム間でコードを共有し、MicrosoftのProject Linker ツールを使用してこれらをリンクする
  • クラス ライブラリ内で #define コードを使用して、プロジェクトのプラットフォーム固有の実装を提供します (私は個人的にこのアプローチを避けようとしていますが、多くの場合、市場への最短ルートを提供します)。
  • DI/IoC 技術を使用して、プラットフォーム固有の実装が本当に必要な場合に備えてコンポーネントを提供します。
  • アセンブリ リンクを使用して IoC を提供する - たとえば、これはXamarin MobileAPIが行うことです
  • 本物の共有機能にサーバーベースのロジックを使用する - たとえば、REST または SOAP-XML サービスを使用してロジックを実装する
  • プラットフォーム間でテスト (NUnit など) を共有して、ロジックの品質を保証する
  • UI「コントローラー」ロジック用の共有コード手法 - MVC ( MonoCross ) または MVVM ( MonoMobile.ViewsまたはMvvmCross ) を使用する。「ビューレベル」の抽象化のための MonoTouch.Dialog および MonoDroid.Dialog。UI「描画」用のCrossGraphics ; データベース用の SQLite.Net; 等

私は、MonoTouch、MonoDroid、および Microsoft ツールが、クロスプラットフォーム コードの開発において真に重要なメリットをもたらすことを発見しました。

于 2012-05-18T18:11:44.730 に答える