Webにデスクトップから - ドメインモデルを作成します

       武漢神は、神が中国を祝福、祝福します。全国人民武漢の人々のためのメイクの偉大な犠牲が強いとの役割を果たしています。

  流行時に、この自己分離の1つの副作用は、この長期休暇を楽しむことが最初でした、Web技術を学びたいと思っていたが、自宅で1つのコンピュータのみが占有され、見し続けるために、唯一の最後を停止ドメインモデルのオープンソースプロジェクト。

  ミキシングプラントの生産管理は、コアの拡張のために短期的な事業計画に基づいており、日々の生産スケジューリングのスタッフがサイトのニーズに応じて作成した「毎日の計画」を策定します。研究室の担当者は、その日のプログラムの生産レシピを作成します。生産は、彼が多くの小さなバッチプログラムに分けられますが、継続的な毎日のスケジュールではありません。バッチプログラムの分解は、コンクリートポンプトラックの注入によって指定された場所に、最終的に最初にミキサーで現場に輸送ステーションを、混合することにより製造多くのステップは、ある具体的な配信、およびするためです。この製造方法によれば、我々は簡単にモデルの元のバージョンを設計することができます

  そして、実際の生産工程は、いくつかの特別な場合のために、バッチプログラムは、いくつかの追加のアクションを追加します、一般的な、日常の最初のバッチは、(ポンプ吐出チューブを潤滑するために使用)追加のモルタルが生成されます、これが初めての開口部のためのサイトですが、また、品質の本を印刷する場合。バッチは、これらの追加のアクションを含めることが報告さバッチプログラムをオブジェクトの前にこのようなプログラムは、大きくする必要があります。

  あなたは慎重に上記の目的を分析する場合は、追加のアクションや生産計画や行動の配信は、彼らが実行するか、あきらめることができるかどうか、あなたは本質的に実行可能な対象であるアクションの実装の結果を追跡する必要があります。及び(なぜなら車両の問題ではなく、具体的な部位に、例えば)アクションの結果に応じて行ってもよいし、いくつかの補償は、後続のアクションを開始することができます。ここで再び我々は、動作モード(Martin Fowler氏の分析モード)を導入することができます。

   アクションモードでは、我々は、提案されたアクションを採用することができ、その差は、返されたため、品質上の問題で8平方コンクリートとコンクリートを送信するためにサイトの計画として提案、の行動トラッキング動作と実装を行うために、より便利です。

  行動の結果が正常に実行するかどうかを、最も簡単な方法は、標準のプロパティを使用することです。これは欠点の方法は、障害の原因を記録することができない、我々は唯一のアクションが失敗したかどうかを記録することができますことを、あまりにもシンプルです。そのようなリターンによって引き起こされる具体的な障害などの指標の数のサイトへのサイト。ここでのより良いアプローチは、あなたが具体的な指標の検査記録を観察し、記録することができ、観察モードを使用することです。そして、操作を観察した結果が成功したかどうかによって判断します。これは、より柔軟な決意論理結果を提供することができます。

   動作モードの導入後、我々は構成および依存の動作を実現するプログラムの種類を使用することができ、動作プログラムは、本質的に逐次重合(Martin Fowler氏分析モード)です。

  ここでは、計画と日々の計画バッチは、計画のサブタイプとして使用することができますが、プログラム内のスーパークラスでの生産を増加させつつ、日々の計画バッチプログラムの種類にプロパティを割り当てを増やすための方法を必要としています。あなたが車の輸送能力に応じた生産バッチを決定することができるように、車両を開発する一般的な必要性にバッチプログラムを割り当てる方法で。いくつかの特別な場合には、すべての車両のパーティセットバッチボリュームの船団によって輸送能力に最小限の収率を生じることが期待され、車両を指定しなくてもよいです。一部のソフトウェアでは、同様の問題が辞書に配置されます、これは良い方法ではありません、彼は非常に簡単な解決策になることができますが、論理データ自体を辞書フィールドの数が多いとの混合は、原因を理解することは困難な概念であります多くの問題。最低限の輸送能力は、サービスドメインモデルオブジェクトによって提供されるべきです。しかし、私たちのシステムは、車両管理サービス・インターフェースから取得する準備ができて機能が割り当てられているすべての車両のない論理的な車両管理が含まれていません。それでも、私たちは、内蔵の車両モデルを使用して管理領域をサポートするために、戦略パターンを使用するように用意されています。

  計画のもう一つの問題は、リソースの消費量です。リソース私たちの懸念主にコンクリートポンプ車の原材料の消費量、コンクリート混合駅の生産、輸送および励起ミキサーの生産。資源としての植物を混合コンクリートは、他の優先領域がないシステムのために少し値として、他のサービス管理、リソース管理、トラックが提供するミキサーとポンプコア我々の注目のオブジェクト、ミキサーとして、モデルによって占められているところ。だから我々は、より簡略化されたリソース配分モデルを使用することができます。

   資源配分モデルでは、コアが提案アクションのためのリソース割り当てを予定されている、アクションの実装では、我々は正確に生産操作と配信アクションとの完全な材料の実際の消費量を、数えることができるように、実際のリソースを消費しています場合は、あなたが成功した生産量と消費側の正確な統計情報を提供することができ、完全に正確ではありません。

  予備の進化はMartin Fowler氏の分析モードから重く借りたコンクリート混合工場の生産計画モデル、上に記載されています。もちろん、知識のこの予備的なモデルでは、私たちが再構築するための多くの不合理な待ち時間があります。

  ドメインモデルを使用した後、各プロセスがプロセスに設計されており、ドメインの多数のオブジェクトを実行され、これは、UI層多大な困難を呼び出しますし、ドメインオブジェクトの数が多いとUI層の設計、ドメイン知識は必然的にもたらすとき、リークは、これを行う、私たちは、シンプルなインターフェースを提供しながらドメインモデルへの呼び出しをカプセル化するために、アプリケーション層を追加します。今では、この点で、ファサードオブジェクト(ファサード)は密接ページ実装によって関連している可能性があり、より多くの人との対話のソフトウェアが必要です。使用ストレージドメイン・モデルは、データのための大きな課題であるが、幸い私たちはにも、技術的なフレームワークオブジェクトを達成するのを助けるために多くの実績のあるソリューションが存在するデータベースのマッピングが。

公開された132元の記事 ウォン称賛15 ビュー10000 +

おすすめ

転載: blog.csdn.net/ling_76539446/article/details/104184643