web-dev-qa-db-ja.com

Xamarin共有プロジェクトとポータブルクラスライブラリ

私は、どちらが私たちのプロジェクトに行くためのより良い方法であるかを理解しようとしています。

XamarinによるPCLライブラリまたは共有プロジェクト。

Xamarinのドキュメントリンクはこちら 経験則では、ライブラリを共有しない場合は共有プロジェクトを選択することを示しています。共有プロジェクトは、複数のプラットフォームで確実に機能するように#ifを使用して作成できます。これにより、＃ifがアクティブでない場合のリファクタリングに関する問題も発生します。

それでも、このコードを共有クラスに配置するのは正しくないと直感しています。 Windowsで利用できるコードの場合、AndroidおよびIOSモバイルプラットフォームはPCLではなく共有プロジェクトを使用しています-つまり、＃ifsを使用していることを意味しますプラットフォーム固有のプロジェクトでプラットフォーム固有のコードを記述する代わりに、共有プロジェクト内。

これは、＃ifsを介して非PCLアイテムのサポートを作成し、共有コードをより複雑にし、保守を困難にすることを目的としています。これは、.NET PCLコードベースを改善するためにXamarinによって実行される作業ではありませんか？

また、これは、プラットフォーム固有のプロジェクトではなく、共有プロジェクトにプラットフォーム固有の機能を配置していることを意味します。つまり、特定のプラットフォームの複雑さをプラットフォームプロジェクト自体から隠しているため、アーキテクチャの観点からは間違っていると感じます。

私は正しいですか（その場合、Xamarinのドキュメントと競合しています）、それとも何かが足りませんか？

android.netmonoxamarinportable-class-library
27
user3141326

どちらにも場所があります。たとえば、インターフェイスをPCLに配置し、実装に適切な量の共有コードがある場合は、共有コードにインターフェイスを実装できます。

コンパイラフラグも好きではありません。部分クラスを使用したいと思います。このようにして、コンパイラフラグの大部分またはすべてを回避できます。 Class1.csは共有プロジェクトに入り、残りはプラットフォーム固有のプロジェクトに入ります。

Class1.cs
Class1.ios.cs
Class1.Android.cs
Class1.wp8.cs
20
SKall

彼らは両方とも彼らの場所を持っています。コードが完全に移植可能である場合は、PCLを使用することをお勧めします。プラットフォーム固有のAPIを使用する必要がある場合は、さまざまな手法（通常、機能の移植可能な抽象化の作成を含む）を使用してPCLでそれを行うことができますが、それが孤立したケースである場合は、＃ifを使用する方が簡単な場合があります。

長所と短所の一般的なリストについては、 PCLとリンクファイル に関する質問への私の回答を参照してください。共有プロジェクトはリンクされたファイルに似ていますが、ツールの欠点はいくつかありません。

6
Daniel Plaisted

私の印象では、PCLがサポートしていない機能であるという理由だけで、共有ライブラリの利点の下にコンパイラ指令がリストされていました。

あなたとXamarinの両方が欠点を認識しているため、これをXamarinからの励ましとして扱うべきではありません。

だから「賢く」。

2
Lex Li

共有ライブラリと部分クラスを非常に効果的に使用して、強力なMVVMを備えた英国の大手衣料品小売業者向けに構築された大規模なXamarin.iOSおよびXamarin.Androidアプリを見てきました。 IFDEFを使用する必要がある非常に具体的なシナリオは2つだけです。その経験から、私はデフォルトでこのルートに行くことがよくありました。

そうは言っても、.NET標準2.0が登場することに注意してください。これにより、独自のアプローチ（PCLと似ていますが、実際にはまったく異なります）がもたらされるため、この議論は一般的な質問ではなくなります... https： //blogs.msdn.Microsoft.com/dotnet/2016/09/26/introducing-net-standard/

0
Michael