🦈 👰🏽 💭 複数の画面に関するいくつかの質問。（.NET） 👍🏾 💧 👋🏿

プロローグ

この記事は、そのような記事ではないため、誰かのお気に入りに含まれることはほとんどありません。初心者向けの知恵の編集はありません。コードは1行もありません。注意を引く写真はありません。むしろ、この投稿は単純なプログラマーからアウトソーシング会社への質問と考えです。したがって、 IT企業のオフィスの喫煙室からのカットと接着された対話（まあ、この場合はむしろ、独白）に何らかの形で似ています。 .NET CMS OrchardとUmbracoに精通している開発者に多くの質問に答えることができるでしょう。念のため、あなたの知性に訴えたいと思います-ここで聖戦を手配しないでください。結局のところ、長所と短所はどこにでもあり、さらに、1つの問題に対する2つの一般的な解決策が存在するため、それらの比率はほぼ1に等しいことを長い間理解しています。また、私は結果のタオルについて謝罪したいと思います。

1つのプロジェクトでCMSを実行した方法

2010年、パートナーと私はクライアントのプロジェクトに行きました。彼の義務のために（詳細はわかりませんでした）、サードパーティのコンポーネントを使用できませんでした。マイクロソフト自体がサードパーティのオープンコンポーネントを自社製品に導入しているという事実を考慮して、クライアントはマイクロソフト製品で提供されるものを使用できることを指定しました。クライアントには独自のIT部門があり、そこで予備分析が行われ、いくつかの作業も開始されました。私たちは、ほとんどサイクルの最初に接続しました。 IT部門は、以前の経験を活用して、基地で非常に良い仕事をしました。新しいシステムを古いシステムと密接に統合する必要があったため、このステップは正当化されました。そして実際、古いシステムはベースです。フロントエンドとDALは完全に消去され、書き換えられました。ベースは最終的に古い製品と完全に統合されました。開発期間全体で、使用されたいくつかのタイプの技術が置き換えられ、その後、確立された技術の結果としていくつかのバージョンが置き換えられました。多くの仕事がありましたが、すべての自尊心のあるプログラマーのように、「落ち込む」ためではなく、「病気になる」ために働きました。彼らは毎日、モジュール性を改善する方法、組み立てプロセスを改善する方法について考えました。アジャイルの実践とプロトタイピングの実践の両方をゆっくりと紹介しました。これはばかげているように見えるかもしれません。しかし、骨化したシステムを持つ複雑な顧客がいた人たち-彼らは私を理解するでしょう。敵意がなければイノベーションは受け入れられ、少なくとも攻撃的な批判のフィルターを通過します。私たちの製品に戻って、私たちには多くの革新を提供しました。直交イデオロギーを使用し、プロジェクトのすべてがウィジェットでした。すべてがデータベースを介して構成されました。ウィジェット自体はプラグインでした（ MEF ¹ではなく、EntLib ^3の通常のIoCコンテナーUnity ^2ではありません）。さらに、 AOPの使用が開始されました。すべては既存のCMSに関係なく行われました。もちろん、既存のソリューションを見つめないのは愚かでした。しかし、私たちの文脈では、すべてが論理的でした。最初は、製品はCMSとして表示されませんでした。この顧客は、要件にシームレスに詳細を追加しました。いつものように。もちろん、これには準備ができていました。資金調達や予算の再評価に問題はなかったため、これは常に起こります。偶然に製品をCMSに変え始めたことを明記します。要件の改訂、イベントの回顧、およびクライアントの観点から製品を見て、クライアントの希望を予測する試みのおかげです。通常のDRYプラクティス、Agile ⁴プロセスの導入、直交性、すべてを自動化し、データベースまたは構成ファイルを介してすべてをカスタマイズできるようにする試み、 TFSのアセンブリショップの適切な実装、独自のローカリゼーションシステム、独自のテーマエンジン、パフォーマンスコントロール、および一定のリファクタリング（しかし実際には-クライアントの次のラウンドでシステムのコア部分を書き換えることもあります）、そしてそれ自体が製品につながり、プログラマーが「 CMSについて何を書いているのですか？」私たちがやっていることにラベルを付けるのを忘れていたので、私たちの完全な誤解はどうなるでしょう。あなたの許可を得て、私はこの物語をシンプルな結末に変えます-すべてがうまくいきました。私は自分の仕事を恥じていません。私たちが定期的に議論してくれた素晴らしい同僚がいました。この製品はすぐに使用でき、クライアントのゆったりとした時間のおかげで、開発者（すでに5人がいますが、クライアントはマネージャーの構成やIT部門の中核さえも変更しました）は、製品を達成できない完成度まで舐める時間をより多く持っています。したがって、.NET CMSの世界から孤立しているにもかかわらず、独自のCMSを作成しました。プロジェクトを離れた後、無視したオプションを確認することにしました。私たちのオフィスでの公聴会では、UmbracoとOrchardがいました。これらの製品は単に良いものでなければならないことを事前に知っていたので、コードを簡単に見てみることにしました。したがって、彼らの建築ソリューションを見るとき、私たちは自分の製品をどのように改善できるかを知りたいだけでした。実際、ここでこれらのCMSを長い間フォローしてきた人々の意見を知りたいと思います。

オーチャードとウンブラコ5

両方のCMSは、任意のモジュールが依存できるカーネルを使用します。ちなみに、両チームはJetBrains R＃ ^5を使用しています。これは、両方のCMSのコードの表示に素晴らしい効果がありました。また、両方のCMSはORM NHibernate ⁶およびIoC Autofac ^{7を使用し}ます。興味のために、まずこれら2つの事実に焦点を当てたいと思います。最後から始めましょう。

一般的なIoCと拡張性

Umbracoは、シェルインターフェイスのセットを作成することにより、 IoCからの分離を試みました。したがって、開発者はIoCコンテナを自由に使用できます。しかし、私がこれを行おうとすると（プロジェクトで他に選択肢がなかったため、Autofacの代わりにUnity）、面白いことに気づきました。 UmbracoはAutofacインターフェースモデルを単純にコピーしました。つまり Unity上で実際にバインディングを実装することにより、このバインディングはAutofacのように見えます。公平に言えば、この事実を楽しんでいるにも関わらず、それがひどいものであることが判明したことは注目に値します。さて、それがどのように起こったか-それはコンパイルされ、テストはパスします。実験のためだけに試しました。 Umbracoでのこのアプローチについて考えられる説明が1つありますが、間違いなくもっと多くあります。私は真実を知りません。私自身の説明は、 CMSは IoC Autofacに基づいて設計されたということです。そして、開発者は特定のコンテナを無視することにしましたが、コードはすでに記述されており、開発者はすでに構文に慣れていたため、開発に影響を与えませんでした。別のコンテナの使用への移行はとても面白いからです。もちろん、 CMSの変更履歴を確認して、説明を実際に間違っていることを確認するか、それとは反対に放棄することもできますが、この時間はありませんでした。このCMSの開発をフォローしている人がいれば、それについてもっと聞きたいです。いずれにせよ、 IoCを置き換える可能性について開発者に感謝します。開発者は、プロジェクトで複数の異なるライブラリを使用して、1つの問題を解決したくない場合があります。 UmbracoはMEFも使用しますが、驚いたことに、Orchardでは見つかりませんでした。 Umbracoでモジュールを作成するアプローチは、しかし、私には非常に正統的でした。彼らのチームは、独自のタイプのプロジェクトでいくつかのテンプレートを作成しました。この驚くべき量の作業は、わずかな光沢のために行われたことは注目に値します。つまりスタジオでは、Umbracoモジュールプロジェクトに企業アイコンが表示され、このアイコンをクリックするか、このタイプのプロジェクトまたは要素用に開発された独自のアクションセットを持つ要素をクリックします。おそらく視覚的なアシスタントなどがあります...繰り返しになりますが、これはちょっとした光沢のために膨大な量の作業です。ただし、このおかげで、Umbracoはスタジオで完全に「感じられた」ことに注意してください。 Orchardのモジュール開発へのモダニストのアプローチは、多くの人に馴染みのあるscaffolding ⁸とプレーンテキスト形式のマニフェストを使用しますが、この意味ではあまりメリットがありません。すでに述べたように、OrchardはUmbracoと同様に、AutofacをIoCコンテナーとして使用します。すでにこの事実だけで私に疑問を投げかけました。次のMIX ⁹が準備されていたとき、オーチャードはMicrosoftの腸で発生したようです。同時に、オーチャードは、これが何を意味するかに関係なく、「イデオロギー的に純粋な」 CMSとして考えられていました。開発者がMicrosoftでOrchardのように生まれたUnityを使用できなくなったのはなぜですか？また、依存関係管理の問題も解決します。さらに、開発者は、システムのMEFが優れたソリューションであることに気付かない可能性があります。特に、 MEF 2の動向を踏まえると、明らかな開発が現実のものとなりました。 Microsoftのテクノロジーを使用すると、それらを改善できます（Unity、system.ComponentModel.Composition.Web.Mvc名前空間のクラス...）。結局のところ、あるチームでは異なるチーム間のコミュニケーションは、ライブラリの独立した開発者と別の会社の開発者間のコミュニケーションよりも集中的である必要があります。それだけでなく、Orchardはカーネル自体でAutofacを使用します。つまりこのコンテナとの接続は、Umbracoよりもはるかに強力です。マイクロソフトのコミュニケーションは本当に悪いのですか？この件に関して少なくともいくつかのコメントを聞きたいです。システムを使用するという観点からは、これは誰にも迷惑をかけませんが、平和の単純な関心はとにかく私に与えません。

NHibernate ORMおよびデータレイヤー

この質問にはあまり興味がなかったので、1つだけ質問します。それにもかかわらず。なぜこのORMがEFではないのですか？まあ、それはもちろん、NHibernateが長らく待ち望まれていたのに対し、 EFはデータ移行のための通常のソリューションに近づいていることを理解しています。しかし、移行の計画はありますか？ OrchardのNHibernateは、 IoCと同様にコアに緊密に統合されています。 Umbracoは永続的なメカニズムの直交性を処理しました。 Umbracoでは、Umbraco.Framework.Persistence.NHibernateの使用は絶対にオプションです。一般的なデータレベルに関しては、両方のCMSで最高レベルです。どちらにも独自の利点があります。 Umbracoは、本質的に抽象的なデータプロバイダーであるモジュールとHivesの概念の優れた直交性を誇っています。以前のバージョンからUmbracoについて多くの否定的なレビューを聞きました（明らかな理由により、ライブプロジェクトでは、ベータ段階に進まないこのCMSの 5番目のバージョンを使用した人はいませんでした）。 XSLT 、 XML 、メモリを大量に消費する、パフォーマンスの低下に関連するものがありました...このCMSの 5番目のバージョンを見て、以前のバージョンについては何も知りませんでした。そして、私はこのバージョンの従業員から多くのことを聞いたことがあるという問題はまったくないことを理解しています。たぶん以前のバージョンでは、直交性がはるかに悪かった、または従業員が何かを知らなかった-私はこれを知らず、今でも興味がありません。 Orchardはまた、コンテンツタイプシステムを誇っています。これは、タイプの動的な構成を念頭に置いて、 CLRタイプシステムよりもさらに柔軟であると主張しています。

「Orchard」と「Umbraco 5」に夢中になっているのはとてもいいことです

Umbracoはローカリゼーションモジュール^10を実装し、そこから私の脳が爆発しました。彼女はゴージャスです！もっと精巧で強力なローカリゼーションシステムは想像できませんでした。私たちのプロジェクトでは、そのような力は必要ないことを確信しました。実際、私たちと一緒にいたシンプルなローカリゼーションシステムでさえ、すでに顧客の期待の頂点でした。しかし、私たちと同じように、クライアントにはあまり想像力がなかったからです。 Umbraco 5のローカリゼーションモジュールを見ていたため、このCMSの人々の永続性と努力がうれしかったため、後でモジュールの解析を延期しました。多分、次の人生まで。オーチャードは私の脳を食べませんでしたが、それでも、彼らの決定の優雅さが本当に好きでした¹¹ 。たとえば、エンジンの出力は¹²であり、可能なすべての出力を完全に制御します。また、開発しなかったウィジェットの標準出力をオーバーライドするオプションもあります。トピックは面白く、シンプルで、 CMSでも使用したレイアウトとゾーンの多くの概念で理解できますが、Orchardチームはより良く、より良くしましたが、それは理解できます。レシピ¹³ （Webサイトに含めるモジュールを指定するコンポーネントの高度な構成）、ストリーミングコンポーネント、およびシンプルな構成システムの原則に感銘を受けました。すべてがエレガントに行われ、システムでの作業が簡単であるという一定の印象があります。また、コンポーネントの独自のストリーミングを指定できることも言及する価値があります。これは、オーチャードベースのシステムを販売する企業にとって非常に興味深いものであり、コンポーネントはドメインのコンテキストでのみ便利です。これらのコンポーネントは、レシピに手動で追加するか、システムの管理パネルからインストールできます。また、プロジェクトを再構築する必要がないため、モジュールまたはトピックのビューをすばやく変更するのも便利になりました（動的コンパイルのおかげです）。

私が個人的に理解したこと

可能であれば、1つの優れたCMSを学ぶのが最善です。現時点では、たくさんの選択肢があります。それらはすべて直交性を使用し、それを最大化しようとします。つまり、いずれにせよ、あなたは利益を得るでしょう（ささいな静的ページについて話していない場合）、プロジェクトをより少ない驚きで完了し、 CMSを使用しない場合よりもはるかに速く完了することができます。開発者がこれらのシステムで作業しているときに、他の乗り越えられない、または非常に不快な驚きに遭遇するのだろうか（もう一度、Orchard v.1.3とUmbraco v.5のみを検討したことを思い出したい）。コードは最前線にあり、開発者がCMSを使用せずに作成するほとんどのコードよりも、アーキテクチャの観点から見て、よりクリーンで優れています。私は次のプロジェクトのためにオーチャードを選びましたが、それは私の個人的な好みのためだけです。 Umbraco 5は、このCMSのコードを表示した後、Orchardより悪くないことがわかりました。そして、いくつかの場所では、実行の質は上記のカットです。しかし、私が言ったように、私はオーチャードで働いているときの見かけの単純さと「軽さ」の感覚に賄briを受けました。すでにお分かりのように、私にはまだいくつかの質問があり、それらに対する答えがあればそれを知ることは非常に興味深いでしょう。最後までこのタオルを読んでくれてありがとう。

複数の画面に関するいくつかの質問。 （.NET）