Monocross について少し読んだことがありますが、ASP.NET MVC に非常によく似たモデルをサポートしているようです。UI として HTML5/CSS/Javascript を使用できます。
最初に MonoDroid と MonoTouch を直接見てみると、開発者はデバイスにネイティブなコントロールを使用して開発することが奨励されます。Monocross がすべてのデバイスで HTTP/GET/POST を使用して HTML/CSS/Javascript をサポートしているというのは正しいですか? MonoDroid/MonoTouch はクロス プラットフォーム開発を UI までサポートしていますが、このアプローチでは、理論的には 100% (またはほぼ) コードを再利用できるようです。これは正しいです？
MonoCrossは、Xamarinのコードの上にある非常に薄いレイヤーです。（右上隅にあるXamarinステッカーを参照してください？）
MonoTouchやMonoDroidなどのさまざまな実装で同じMVCコードを再利用することを提案しています。
MVCを抽象化すると小さなサンプルで機能しますが、これらの人は100％コード共有を信心深く信じているようです。これは私が購読していないことです。それは美しいコンセプトですが、実際には機能しませんでした。
優れたアプリを作成するのは難しいですが、データベーステクノロジーが異なるため、またはASP .NET MVC、MonoTouch、MonoDroid用に同様のクラスを作成する必要があるため、難しいとは思いません。それがソフトウェア開発の本当の課題だったとしたら、私たちは何年も前にそれを解決していたでしょう。
MonoCrossは、時期尚早の一般化の演習のようです。これは、すべてのプログラマーが大好きなことです。
しかし、抽象化は無料ではありません。エリック・ガンナーソンによるこの逸話を考えてみましょう。
私はこれが雪だるま式に進んだチームを知っています-彼らは多くの異なるシナリオで使用された「スイスアーミーナイフ」コンポーネントになってしまいました。そして、多くのことを行う多くのコンポーネントのように、それは大きく、複雑で、多くの理解しにくい振る舞いをしていました。しかし、それを開発することは、関係する開発者にとって興味深い技術的課題でした（「彼らのキャリアにとって楽しくて良い」と読んでください...）
問題は、チームが1回の操作に必要な時間の約4倍かかることを発見したときに発生しました。しかし、操作を実行するコンポーネントの一般化された性質のため、それを最適化する簡単な方法はありませんでした。
「uber-component」を使用せずに操作をゼロから開発した場合、いくつかの簡単な最適化アプローチを採用できたはずです。ただし、1つのシナリオで最適化を実装するだけではなく、すべてのシナリオで機能する必要があるため、これらはいずれも一般化されたコンポーネントでは機能しません。どこでも機能させるための開発コストを支払う余裕はありませんでした。この場合、たとえ可能であったとしても、他のシナリオではパフォーマンスが低下する可能性があります。
（強調は私のものです。）
MonoCrossの開発者は熱心に取り組んでいるようですが、プロジェクトの周りにはコミュニティがないようで、iFactrまたはMonoCrossの上に構築された単一のアプリを見つけることができませんでした。
そうは言っても、MonoTouchやMonoDroidよりも価値のあるものは何もないと思います。
補足として、ミゲルは承認します:-)。
