今日は、スピーカーと話し合うことができる興味深いトピックについて話し、これらのトピックに無関心でない人を見つけたいと思います。
私たちの会議の主な目的が人々に専門的な興味に基づいて知り合う機会を与えることであることは秘密ではありません。 プレゼンテーションは思考の糧であり、その後のさまざまな詳細度の議論への紹介です。 私たちの意見では、そのようなコミュニケーションは、時には正反対の意見に出会うにつれて、自分自身の信念をより深い程度まで認識させることに貢献します。 それでは、デスクトップUIとビジネスアプリケーション会議の準備は何ですか？
最初に、サーバー側のバックエンドに関連するトピックを想像してください。これは、エンタープライズ開発の分野に関与するすべての開発者にとって興味深いものです。 つまり WPF、WinForm、およびASP.NETの両方です。
ソフトウェアの世界で実際のデータとプロセスを提示する歴史には、豊かで長い歴史があります。 すべてはトランザクションスクリプトと手続き型プログラミングから始まったと言えます。 データベースに格納されている一連の手順とデータの形式でドメインモデルを完全に表現しようとしたとき。 実際、すべてがテーブルを中心に展開されました。 OOPの開発とともに一歩前進したのは、表形式データのモデルであり、プログラムメモリ内のデータセットによって既に表されていました。 現在、テーブルはドメインロジックのプレゼンテーションの出発点になっています。 プロシージャはグローバル名前空間で宣言されなくなりましたが、関数に応じて特定のテーブルに「固定」されました。 コンピュータのコストと流通がさらに削減されたことにより、コンピュータモデリングがより幅広い用途に使用されるようになりました。 同時に、サポートと拡張のために、複雑な実ドメインモデルをできるだけシンプルに表示する必要がありました。 そこで、Martin Fowlerが提案し、Eric EvansがDomain Driven Designのアイデアを開発しました。
ただし、微妙な違いがあります。 マーティン・ファウラーは、貧血領域は本質的にアンチパターンであり、あらゆる方法で避けるべきであると仮定しています。 彼は、行動とビジネスロジックが統合されたリッチドメインモデルと彼女を対比しています。 しかし、本当にそうですか？ 「Enterprise Application Templates」という本が発行された2002年、および「Domain-Driven Design：Tackling Complexity in the Heart of Software」が発行された2003年から何が変わったのでしょうか？ この問題に関する議論は、Garant社の主な開発者であるVlad Klekovkinによって行われます。
ドメインドメインのジャングルに飛び込むと、適切に設計されたドメインモデルがソリューション全体の始まりにすぎないことがすぐにわかります。 リッチモデルであろうと貧血モデルであろうと、良いドメインモデルは特定のケースに依存します-これは静的なデータキャストにすぎません。 インテリジェントなアーキテクトや興味のある人なら、動的モデルも同様に重要であるとすぐにわかります。 動きは人生です。 興味のある人は、 ロザンスキーとウッズを通して見ることができます
.NET Frameworkでは、現実の世界の動きであり、そのイベントは... um ...イベントを使用して表示されます。 私たちの世界の出来事と同じように、それらは無期限にやってくるが、私たちは原則として何が起こるべきかを知っている。 そして、ここから問題が始まります。 サブスクリプションの多くは、サブスクリプションを忘れてしまった-メモリフォグと呼ばれるものやその他の問題につながる可能性があります。 さらに、さまざまなイベントの相互作用、それらのフィルタリング、処理、組み合わせ、さまざまなストリームでの処理の複雑なシナリオには、Monitor、ManualResetEventSlimからTaskFactoryまで完全に異なる低レベルおよび高レベルの抽象化が含まれます。
道路上の動物園。 おそらく多くの場合、最適なソリューションはReactive Extension （Rx）を使用することです。 このライブラリは長い間存在し、常に進化しており、さまざまなニュアンスを持つストリーム処理タスクを正確に目指しています。 マルチスレッドであるかどうか、再試行テンプレートを実装する可能性など、非常にコンパクトな形式です。 このような複雑な実生活の例は、グローバルPSテクリッドのアンドレイ・ダイアトロフが発表します。 さらに、Rxのテストで時間を管理するのがいかに簡単かがわかります。 役に立たない例ではなく、本物のコードだけの合成物。
Rxの代わりにTPL Dataflowを使用できます。 この統合データ処理APIのスイートは、.NET Framework 4.5に含まれています。 誰もがTPLコアに精通しています。 Task <T>を直接使用するだけでなく、後のリリースのasync / await構文シュガーも使用してください。 しかし、ライブラリは唯一の「タスク」ではなく、Actorマルチスレッドモデルに基づいて複雑なデータストリームを処理する機能を提供します。 さらに興味深いのは、RxとTPL Dataflowについてのレポートを聞き、スピーカーに難しい質問をすることです（「arrange a holivar」を読んでください）。 このトピックは、Luxoftのサンクトペテルブルク支社のシニアプログラマーであるMikhail Veselovによって提示されます。
複雑なルールに従って大量のデータストリームを処理する方法について真剣に話し始めた場合、データを取得する場所と保存する場所の問題が常に発生します。 より正確には、それらをどのように取得して保存するか、つまり 選択するORM。 現在、事実上の標準はEntity Frameworkであり、これは積極的に開発および推進されており、すでに7番目のメジャーバージョンに到達しています。 ゴールデンハンマーは良くないということは以前の投稿で既に述べています。常にニーズに合ったツールを選択する必要があります。 MicroORMであるか、NHibernateの精神に沿った本格的な実装であるかなど、ニーズに最も適した新しいツールを探してください。
開発者にとって最も訪問され、ロードされたWebサイトの1つがStackOverflow.comであることはおそらく秘密ではありません。StackOverflow.comは、Linq2SQLを使用してデータを操作します。 私はまだLinq2SQLに対して温かい気持ちを持っていることを認め、より便利なシステムのように思えました。 しかし同時に、「M」プロジェクトから生まれたEFは、CodeFirstテンプレートとDataFirstテンプレートを使用する新しい機会を与えてくれたことを認めます。 ただし、完璧な人はいないため、新しいプロジェクトと機会を探す必要があります。
したがって、そのような新しいORMは、Flexberryプラットフォームの技術専門家であり、ITSK LLCの開発部長であるAndrey Kolchanovによるレポートで議論されます。 EFの形で現在の主力商品に満足していない理由、銀行部門やオンライン決済を含む長年にわたって実際のビジネスにORMを使用している理由を説明します。
長い間、ORM Flexberryは閉鎖的な開発でしたが、どうやら37 Signalsの連中の推奨に従って、取り返しのつかない利益をもたらすために製品を世界にリリースすることが決定されたようです。 Andrewは同じプロジェクトでEFとFlexberryのテストを実行して、2つのアプローチの実際の違いを示します。彼は、EFの主要なポジションに対する自信を揺るがすことができると確信しています。
同僚、私たちの問題を解決するための「銀の弾丸」を提供する技術はありませんが、改善するための最良のツールとプラクティスを探すことができます。 この点での会議は、開発のための良いベクトルを提供し、志を同じくする人々を見つけて反対意見に出会うのに十分な人々を集めます。
4月11日に開催される会議に参加して 、問題をより効果的に解決してください。
