タグ付けされた質問 「architecture」

Facebookなどのソーシャルネットワークなど、高度にスケーラブルである必要があるWebサイトの場合、Webサイトを設計する最良の方法は何ですか？ サイトが必要なデータを取得するためにクエリするWebサービスが必要ですか？ または サイトはデータベースを直接照会する必要がありますか？（組み込みの言語構造を使用して、テーブルに自動的に入力するなどを行うことができます）。 ウェブサービスは一元化されたデータアクセスを提供し、キャッシングなどの制御がはるかに簡単になるため、より良いデザインだと思いますが、他の人はどう思いますか？

35 design  architecture  websites  scalability 

今後数か月で、クライアント用に構築したシステム（v1）を取得し、ゼロから再構築するプロジェクトを開始します。v2の目標は、この特定のクライアントが使用する独自のモジュールセットを持ち、別のクライアントが異なるモジュールセットを完全に使用できるようにモジュール化することです。ここでのコツは、会社Aがそのシステムの動作を変更する一連のチェックアウトおよびユーザーモジュールを持っている可能性があることです。会社Bは、標準のチェックアウト手順に固執するかもしれませんが、製品の閲覧方法をカスタマイズします。 アプリケーションをゼロから構築しCore、すべてのクライアントで共有したい一方で、クライアント専用に変更するものの柔軟性を維持したい場合、アプリケーションアーキテクチャへの良いアプローチは何ですか？ CodeIgniterのフックを見たことがありますが、250のフックになる可能性があり、まだ十分な柔軟性がないため、これは良い解決策ではないと思います。他のソリューションは何ですか？理想的には、砂の中に線を引く必要はありません。

34 php  architecture  mysql  modules 

ストアドプロシージャは、マイクロサービスアーキテクチャで悪い習慣と見なされますか？ 私の考えは次のとおりです。 マイクロサービスに関するほとんどの書籍では、マイクロサービスごとに1つのデータベースを推奨しています。通常、ストアドプロシージャはモノリシックデータベースで機能します。 繰り返しますが、ほとんどのマイクロサービスアーキテクチャの本は、自律的で疎結合である必要があると述べています。特にOracleで作成されたストアドプロシージャを使用すると、マイクロサービスとそのテクノロジが緊密に結合されます。 私が読んだほとんどのマイクロサービスアーキテクチャの本は、マイクロサービスをビジネス指向（ドメイン駆動設計（DDD）を使用して設計）にすることを推奨しています。データベースのストアドプロシージャにビジネスロジックを移動することにより、これはもはや事実ではありません。 これについて何か考えはありますか？

34 architecture  microservices 

私たちの大部分が大規模なアプリケーションでは、通常、「定数」の場所はわずかしかありません。 GUIおよび内部定数（タブページのタイトル、グループボックスのタイトル、計算係数、列挙）の1つのクラス データベースのテーブルと列用の1つのクラス（この部分は生成されたコードです）およびそれらの読み取り可能な名前（手動で割り当てられた） アプリケーションメッセージ（ロギング、メッセージボックスなど）の1つのクラス 定数は通常、これらのクラスの異なる構造体に分けられます。C ++アプリケーションでは、定数は.hファイルでのみ定義され、値は.cppファイルで割り当てられます。 利点の1つは、すべての文字列などが1つの中央の場所にあり、何かを変更する必要があるときに誰もがどこにあるかを知っていることです。 これは特に、プロジェクトマネージャーが人々が行き来する際に好むように思われるものであり、このようにして誰もがアプリケーションの構造を掘り下げることなく、このような些細なことを変更できます。 また、同様のグループボックス/タブページなどのタイトルを一度に簡単に変更できます。別の側面は、そのクラスを印刷して、キャプションが直感的であるか、ユーザーへのメッセージが詳細すぎるか、混乱しすぎていないかなどを確認できる非プログラマーに渡すことができることです。 ただし、いくつかの欠点があります。 すべての単一クラスは、定数クラスに密接に結合されています 定数の追加/削除/名前の変更/移動には、アプリケーションの少なくとも90％の再コンパイルが必要です（注：少なくともC ++の場合、値の変更は行われません）。1500クラスのC ++プロジェクトの1つでは、これは約7分間のコンパイル時間（プリコンパイル済みヘッダーを使用し、ヘッダーなしでは約50分）に加えて、特定の静的ライブラリに対する約10分間のリンクを意味します。 Visual Studio Compilerを使用して速度が最適化されたリリースをビルドするには、最大3時間かかります。膨大なクラス関係がソースであるかどうかはわかりませんが、そうであるかもしれません。 何かを非常に迅速にテストしたいので、そのテスト（そしておそらくその後のすべてのテスト）だけで15分待ちたくないので、一時的に直接コードに文字列をハードコーディングすることになります。「後で修正します」という考え方に何が起こるかは誰もが知っています。 別のプロジェクトでクラスを再利用するのは必ずしも簡単ではありません（主に他の密結合によるものですが、定数の処理はそれを容易にするものではありません）。 そのような定数をどこに保存しますか？また、プロジェクトマネージャーに、上記の利点に適合するより優れた概念があることを納得させるために、どのような議論を提起しますか？ C ++固有の回答または独立した回答をお気軽にお寄せください。 PS：私はこの質問が一種の主観的なものであることを知っていますが、正直に言って、この種の質問についてこのサイトよりも良い場所を知りません。 このプロジェクトの更新 コンパイル時間に関するニュースがあります 。Calebとgbjbaanbの投稿に続いて、時間があるときに定数ファイルをいくつかの他のファイルに分割しました。私は最終的にプロジェクトをいくつかのライブラリに分割しましたが、これは今でははるかに簡単になりました。これをリリースモードでコンパイルすると、データベース定義（テーブル、列名など-8000を超えるシンボル）を含む自動生成ファイルと特定のハッシュを構築することにより、リリースモードで膨大なコンパイル時間が発生することがわかりました。 DB定数を含むライブラリのMSVCオプティマイザーを非アクティブ化すると、リリースモードでのプロジェクト（複数のアプリケーション）の合計コンパイル時間を最大8時間から1時間未満に短縮できるようになりました。 MSVCがこれらのファイルを最適化するのにこれほど苦労する理由はまだわかりませんが、今のところ、ナイトリービルドのみに依存する必要がないため、この変更により大きなプレッシャーが軽減されます。 その事実、およびより緊密でない結合、より良い再利用性などのその他の利点も、「定数」の分割に時間を費やすことは、結局のところそれほど悪い考えではないことを示しました;-) Update2 この質問にはまだ注目が集まっ ているので、ここ数年私がやってきたことは次のとおりです。 関連するスコープにすべての定数、変数などを正確に配置します。単一のメソッドでのみ定数を使用する場合、そのメソッドで定義することは問題ありません。単一のクラスに興味がある場合は、そのクラスのプライベート実装の詳細として残します。同じことが名前空間、モジュール、プロジェクト、会社の範囲にも当てはまります。ヘルパー関数などにも同じパターンを使用します。（パブリックフレームワークを開発する場合、これは100％適用されない場合があります。） これにより、再利用性、テスト容易性、および保守性が向上し、コンパイル時間（少なくともC ++）が少なくなるだけでなく、バ​​グ修正にかかる時間が短縮され、新しい機能を実際に開発する時間が増えます。同時に、より多くのコードをより簡単に再利用できるため、これらの機能の開発は高速になります。これは、中央定数ファイルが持つ利点よりも重要です。 詳細を知りたい場合は、特にインターフェイス分離の原則と単一責任の原則をご覧ください。 あなたが同意する場合、この更新は基本的に彼が言ったことに対するより一般的な見解なので、カレブの答えに賛成です。

34 architecture  development-process  solid  coupling 

でイベント駆動型アーキテクチャイベントがシステムを介して送信されたときに各コンポーネントにのみ作用します。 ブレーキペダルとブレーキライトを備えた架空の車を想像してください。 ブレーキライトターンにそれが受信したときbrake_onのイベントを、そしてオフそれが受信したときbrake_offのイベント。 ブレーキペダルは、送信brake_onのそれが押下されたイベント、およびbrake_offの、それが解放されるイベントを。 これは、ブレーキペダルが既に踏み込まれた状態で車の電源が入る状況になるまで、すべてうまくいきます。ブレーキライトはbrake_onイベントを受け取ったことがないため、消灯したままになります。これは明らかに望ましくない状況です。デフォルトでブレーキライトをオンにすると、状況が逆転するだけです。 この「初期状態の問題」を解決するために何ができますか？ 編集：すべての応答をありがとう。私の質問は実際の車に関するものではありませんでした。車では、状態を継続的に送信することでこの問題を解決しました。したがって、そのドメインにスタートアップの問題はありません。私のソフトウェアドメインでは、そのソリューションは多くの不必要なCPUサイクルを使用します。 編集2：@gbjbaanbの答えに加えて、私は次のようなシステムに行きます： 架空のブレーキペダルは、初期化後、その状態でイベントを送信し、 仮想ブレーキライトは、初期化後、ブレーキペダルからの状態イベントを要求するイベントを送信します。 このソリューションでは、コンポーネント間の依存関係、競合状態、失効するメッセージキュー、および「マスター」コンポーネントはありません。

33 architecture  event-programming 

私はこの記事を読んだばかりで、混乱しています。 1つのwebappと1つの別個のアプリケーションが「ワーカー」として動作し、両方が同じデータベースを共有しているとしましょう。 ああ、私は「共有」と言いました。しかし、この記事は何について警告していますか？： 第4に、アプリケーション（またはサービス）間でデータベースを共有することは悪いことです。そこに無定形の共有状態を置くのはあまりにも魅力的であり、それを知る前に、巨大に結合したモンスターができます。 =>反対。別個のアプリケーションが依然として同じユニットの一部である場合があります。したがって、この場合、「カップリングの問題」という概念は意味がありません。 続けましょう：webappはクライアントHTTPリクエストを処理し、いつでもいくつかの集約（DDD用語）を更新して、対応するドメインイベントを生成します。 ワーカーの目標は、必要なジョブを処理することにより、これらのドメインイベントを処理することです。 ポイントは： イベントデータをワーカーに渡す方法 読んだ記事が推進する最初の解決策は、優れたメッセージ指向ミドルウェアであるRabbitMQを使用することです。 ワークフローは簡単です： Web dynoがイベントを生成するときはいつでも、RabbitMQを介してイベントを発行し、ワーカーにフィードします。 欠点は、潜在的な送信エラーやハードウェアの問題に対処せずに、集約更新のコミットとイベントの発行の間の即時の一貫性を保証するものがないことです。それは別の主な問題です。 例：集約の更新が成功せずにイベントが発行された可能性があり、その結果、ドメインモデルの誤った表現を表すイベントが発生しました。 グローバルXA（2フェーズコミット）が存在すると主張できますが、すべてのデータベースまたはミドルウェアに適合するソリューションではありません。 それでは、この即時の一貫性を確保するための優れたソリューションは何でしょうか？： IMO、集計更新と同じローカルトランザクションでデータベースにイベントを保存します。 シンプルな非同期スケジューラが作成され、データベースから現在の未公開イベントをクエリし、それらをRabbitMQに送信します。RabbitMQはワーカーにデータを入力します。 しかし、なぜwebapp側で余分なスケジューラーが必要なのか、そしてところで：この場合RabbitMQが必要なのはなぜですか？ このソリューションでは、特にデータベースが共有されているため、RabbitMQは不要である可能性があります。 実際、どのような場合でも、即時一貫性にはデータベースからのポーリングが含まれることがわかりました。 したがって、なぜワーカーはこのポーリングに直接責任を負わないのでしょうか？ したがって、なぜWeb上の多くの記事が、データベース指向のキューイングを批判しているのに、メッセージ指向のミドルウェアを宣伝しているのか疑問に思います。 記事の抜粋： シンプルで、仕事に適したツールを使用します。このシナリオは、メッセージングシステムを求めています。上記のすべての問題を解決します。これ以上のポーリング、効率的なメッセージ配信、完了したメッセージをキューからクリアする必要、共有状態はありません。 そして、即時の一貫性は無視されますか？ 要約すると、データベースが共有されているかどうかにかかわらず、ケースが何であれ、データベースポーリングが必要なようです。 いくつかの重要な概念を見逃しましたか？ ありがとう

33 architecture  domain-driven-design  message-queue  middleware 

これはプログラミング言語にとらわれない質問かもしれませんが、.NETエコシステムを対象とした回答に興味があります。 これがシナリオです：行政用のシンプルなコンソールアプリケーションを開発する必要があるとします。アプリケーションは、車両税に関するものです。これらの（のみ）次のビジネスルールがあります。 1.a）車両が自動車で、所有者が最後に税金を支払ったのが30日前であれば、所有者は再度支払う必要があります。 1.b）車両がバイクで、所有者が最後に税金を支払ったのが60日前であれば、所有者は再度支払う必要があります。 つまり、車がある場合は30日ごとに支払う必要があり、バイクがある場合は60日ごとに支払う必要があります。 システム内の各車両について、アプリケーションはそれらのルールをテストし、それらを満たさない車両（プレート番号と所有者情報）を印刷する必要があります。 私が欲しいのは： 2.a）SOLID原則（特にオープン/クローズド原則）に準拠します。 私が欲しくないのは（私が思うに）： 2.b）貧弱なドメイン。したがって、ビジネスロジックはビジネスエンティティ内に配置する必要があります。 私はこれから始めました： public class Person // You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. { public string Name { get; set; } public string Surname { get; set; } } public …

33 c#  .net  design  architecture 

私のシナリオは次のとおりです。 さまざまな種類のセンサーからデータを受信し、後でさまざまなフロントエンドおよび分析サービスで使用できるように変換して保持するように設計されたシステムを設計しています。 私はすべてのサービスを可能な限り独立したものにしようとしていますが、問題があります。チームは、使用したいDTOを決定しました。外向きサービス（センサーデータ受信者）は、独自の方法でデータを受信し、JSONオブジェクト（DTO）に変換して、メッセージブローカーに送信します。メッセージのコンシューマーは、センサーデータメッセージの読み取り方法を正確に知ることができます。 問題は、いくつかの異なるサービスで同じDTOを使用していることです。更新プログラムは複数の場所に実装する必要があります。明らかに、ここでDTOのいくつかの余分なフィールドや不足しているフィールドを設計しました。サービスが更新されるまで問題はあまりありませんが、それでも私を悩ませ、気分が良くなります。間違いを犯す。簡単に頭痛になります。 システムを間違って設計しようとしていますか？そうでない場合、これを回避する方法は何ですか、または少なくとも私の心配を緩和するために？

33 architecture  microservices  architectural-patterns  dto  pubsub 

通知システムマネージャーを作成する必要があります。 私の要件は次のとおりです。 異なるプラットフォームで通知を送信できる必要がありますが、これは完全に異なる場合があります（たとえば、SMSまたはEメールのいずれかを送信できる必要があります）。 通知は、特定のプラットフォームのすべての受信者で同じ場合もありますが、プラットフォームごとの受信者（または複数）ごとの通知である場合もあります。 各通知にはプラットフォーム固有のペイロードを含めることができます（たとえば、MMSにはサウンドまたは画像を含めることができます）。 システムはスケーラブルである必要があり、アプリケーションまたはサーバーをクラッシュさせることなく、非常に大量の通知を送信できる必要があります。 これは2段階のプロセスです。最初に顧客がメッセージを入力し、送信先のプラットフォームを選択します。その後、リアルタイムで処理されるように通知を作成する必要があります。 次に、システムはプラットフォームプロバイダーに通知を送信する必要があります。 今のところ、私はいくつかの結果になりますが、どれだけスケーラブルであるか、またはそれが良いデザインであるかどうかはわかりません。 私は次のオブジェクトを（疑似言語で）しました： 汎用Notificationオブジェクト： class Notification { String $message; Payload $payload; Collection<Recipient> $recipients; } 次のオブジェクトの問題は、受信者が1.000.000だったらどうなりますか？Recipientオブジェクトが非常に小さい場合でも、メモリを大量に消費します。 受信者ごとに1つの通知を作成することもできますが、一部のプラットフォームプロバイダーはバッチで送信する必要があるため、複数の受信者で1つの通知を定義する必要があります。 作成された各通知は、DBやRedisなどの永続ストレージに保存できます。 これを後で集約してスケーラブルであることを確認するのは良いことでしょうか？ 2番目のステップで、この通知を処理する必要があります。 しかし、適切なプラットフォームプロバイダーへの通知をどのように区別できますか？ をMMSNotification拡張するようなオブジェクトを使用する必要がありabstract Notificationますか？または何かのようなNotification.setType('MMS')？ 大量の通知を同時に処理できるようにするには、RabbitMQのようなメッセージングキューシステムが適切なツールであると考えています。それは...ですか？ これにより、大量の通知をキューに入れ、複数のワーカーに通知をポップして処理させることができます。しかし、上記のように受信者をバッチ処理する必要がある場合はどうなりますか？ 次に、プラットフォームプロバイダーを接続して通知を実行するために、それぞれNotificationProcessor追加できるオブジェクトを担当することを想像します。NotificationHandlerNotificationHandler を使用しEventManagerて、プラグイン可能な動作を許可することもできます。 フィードバックやアイデアはありますか？ お時間をいただきありがとうございます。 注：私はPHPでの作業に慣れており、おそらく選択した言語です。 編集 （morphunrealの答えによる） 1秒間に送信するメッセージの数（現在/初期レベルを定義し、再設計する前にシステムが処理する必要がある最大レベルを定義します） システムのハードウェア制約（システムで使用可能なメモリ、CPUなど） ハードウェアはどのように拡張されますか（つまり、サーバーの追加、クラウドコンピューティングなど） どの言語/システムが通知を生成しますか？ 通知はプログラムで作成しますが、UIから作成するのは私自身です。 ジェネレーターはメッセージの受信者を知っていますか（？）、または他の手段で提供されていますか（つまり、特定のアラートタイプのビジネスルールは特定の受信者に送信されます） 特定の受信者、受信者のグループ（たとえば、タグシステムを使用）、またはプラットフォーム全体に対して通知を作成できる必要があります。 CC / BCC /開封確認を追加するためのビジネスルールはありますか はい。これは実際にはプラットフォーム固有であり、readまたはccはすべてのプラットフォームで利用できるわけではないことに注意してください。 …

32 design  architecture  performance  object-oriented-design  scalability 

私は、ソフトウェアデザインの観点から分析するオープンソースソフトウェアを選択する必要があるソフトウェアデザインクラスを受講しています。 それは大きなプロジェクトでなければなりません：100,000行以上のコード。 優れたソフトウェア設計に関する優れた洞察を得るために、非常によく設計され、設計されたソフトウェアを選択したいと考えています。 良い設計とは、意味のあるクラスとアーキテクチャ、（設計）パターンの適切な使用、抽象化の適切な使用、コンポーネントの適切な編成、コンポーネント間の高い凝集性と低い結合などを意味します。 私に提案するソフトウェアはありますか？ ソフトウェアには適切な設計が必要なだけで、設計を文書化する必要はありません。:) エンドユーザー用のアプリケーションである必要はありません...また、ライブラリ、ツールなどにすることもできます...

32 design  design-patterns  architecture 

私の会社には、プログラミングからアーキテクチャに移行したい開発者が数人います。ソフトウェアアーキテクチャの理論と実践に関する最高の本は何ですか？可能であれば、カバー写真を含めてください。 一般的な本、および特定の技術に関連する本を自由に含めてください。

32 books  architecture 

私がフロントエンドを持っていると仮定します。フロントエンドは、ほとんどが角ばった、うなり声、お辞儀を使って書かれた単一ページのアプリケーションです。そして、私がバックエンドを持っていると仮定します。ほとんどの場合、ORMの上に置かれたREST APIであり、データベースからオブジェクトを保存/取得し、うなり声、エクスプレス、シークライズなどを使用します。 角度のあるアプリケーションは、ユーザーに表示されるすべての視覚的な処理を行いますが、バックエンドによって提供されるサービスを介したGUIとして機能します。 これらを2つの異なるコードベースに分離し、独立した開発、バージョン管理、継続的統合、開発へのプッシュなどを可能にすることが望ましいでしょう。 私の質問は、これをきれいに行うための方法は何ですか？フルスタックJavaScriptの推奨ベストプラクティスはありますか？ オプション＃1はモノリス、つまり「それらを分離しない」ようです。利点は、ビルドチェーンがシンプルであり、すべてが1か所にあることですが、多くの欠点があるようです。個別にバージョン管理するのが難しく、前面が壊れていると、展開できない背面を意味します。 オプション＃2は準モノリスのようです。フロントエンドビルドチェーンにより、多数のファイルがバックエンドに書き込まれます。distフロントエンド上のディレクトリをするとき、フロントエンドminifies、uglifiesなどので、基本的に、バックエンドには、いくつかのディレクトリを参照することになり、それがすべてを実行し、バックエンドに公開してしまいます。 オプション＃3は完全に分離されているようです。フロントエンドとバックエンドはそれぞれ異なるポートで独自のサーバーを実行し、完全に独立したプロジェクトです。欠点は、互いのポートについて知るように設定する必要があるようです。バックエンドは、フロントエンドからのCORSを許可する必要があり、フロントエンドは、それらのすべてのエンドポイントが予想される場所を知る必要があります。 オプション＃4は、docker-composeなどを使用して、すべてをまとめてリグすることです。 私は他のオプションがあると確信しています。推奨されるベストプラクティスは何ですか？

31 architecture  javascript  node.js  front-end  backend 

友人のグループと私は過去少しの間プロジェクトに取り組んでおり、私たちは私たちの製品に固有のシナリオを表現する素晴らしいOOP方法を発明したかったのです。基本的に、私たちは東方スタイルの 弾丸地獄ゲームに取り組んでおり、私たちが思いつく可能性のある弾丸のあらゆる行動を簡単に表現できるシステムを作りたかったのです。 それがまさに私たちがやったことです。Unityのコンポーネントシステムのように、弾丸の動作を自由に弾丸インスタンスにアタッチできるさまざまなコンポーネントに分割できる、非常にエレガントなアーキテクチャを作成しました。うまく機能し、簡単に拡張可能で、柔軟性があり、すべてのベースをカバーしていましたが、わずかな問題がありました。 また、アプリケーションには大量の手続き生成が含まれます。つまり、弾丸の動作を手続き的に生成します。なぜこれが問題なのですか？さて、弾丸の動作を表現するためのOOPソリューションは、エレガントではありますが、人間なしで作業するのは少し複雑です。人間は、論理的で賢い問題の解決策を考えるのに十分賢いです。手続き型生成アルゴリズムはまだそれほどスマートではなく、OOPアーキテクチャを最大限に活用するAIを実装するのは難しいことがわかりました。確かに、それはアーキテクチャの欠陥であり、すべての状況で直感的ではないということです。 したがって、この問題を解決するために、さまざまなコンポーネントによって提供されるすべての動作を基本的にbulletクラスに押し込みました。これにより、想像できるすべてが、他の関連するコンポーネントインスタンスではなく、各bulletインスタンスで直接提供されます。これにより、手続き生成アルゴリズムの操作が少し簡単になりますが、現在の弾丸クラスは巨大な神オブジェクトです。これは、他のコードの5倍以上のコードを持つ、これまでのプログラムで簡単に最大のクラスです。維持するのも少し苦痛です。 別の問題で作業しやすくするために、クラスの1つが神のオブジェクトに変わっても大丈夫ですか？一般に、別の問題に対する簡単な解決策を認めている場合、コードにコードの匂いがすることは問題ありませんか？

31 object-oriented  architecture  code-smell 

現在作成しているアプリケーションは、ストアドプロシージャと手作りのクラスモデルを使用してデータベースオブジェクトを表現しています。一部の人々はEntity Frameworkの使用を提案しており、私はプロジェクトにそれほど遠くないので、それに切り替えることを検討しています。私の問題は、EFを主張する人々が悪い面ではなく、良い面だけを教えてくれると感じていることです:) 私の主な懸念は次のとおりです。 DataAnnotationsを使用してクライアント側の検証が必要であり、とにかくクライアント側のモデルを作成する必要があるように思えるので、EFがそのようなコーディング時間を節約するかどうかはわかりません ネットワークを経由するときにクラスをできる限り小さくしたいのですが、EFを使用すると、多くの場合、不要な追加データが含まれることがあります 複数のデータベースにまたがる複雑なデータベースレイヤーがあり、EFがこれを処理できるかどうかはわかりません。ユーザー、ステータスコード、タイプなどを含む共通データベースと、アプリケーションの異なるインスタンス用のメインデータベースの複数のインスタンスがあります。SELECTクエリは、データベースのすべてのインスタンスに対してクエリを実行できますが、ユーザーは、現在作業しているデータベース内のオブジェクトのみを変更できます。アプリケーションをリロードせずにデータベースを切り替えることができます。 オブジェクトモードは非常に複雑で、多くの場合、多くの結合が関係します EFの引数は次のとおりです。 並行性。各保存の前にレコードが更新されたかどうかを確認するためにチェックをコーディングする必要はありません。 コード生成。EFは私のために部分クラスモデルとPOCOを生成できますが、検証といくつかのカスタム解析メソッドのためにクライアント側モデルを作成する必要があると思うので、これは本当に多くの時間を節約するだろうと確信しています。 すべてのデータベースオブジェクトに対してCRUDストアドプロシージャを作成する必要がないため、開発の速度 現在のアーキテクチャは、パラメーター化されたストアドプロシージャを介してデータベース呼び出しを処理するWPFサービス、WCFサービスとWPFクライアントとの間でやり取りされるPOCOオブジェクト、および検証のためにPOCOをクラスモデルに変換するWPFデスクトップクライアントで構成されますデータバインディング。 私の質問は、EFはこれに適していますか？EFについて私が知らない落とし穴はありますか？

31 architecture  orm  entity-framework 

ソフトウェアの設計と開発の原則について同僚と話したとき、類推の最も一般的なソースの1つは建設業界であることに気付きました。私たちはソフトウェアを構築し、設計と構造をアーキテクチャと見なします。 学ぶ（または教える）ための最良の方法の1つは、類推を分析することです。他の類推は構築から引き出すことができますか？ （ソフトウェアですでに一般的に使用されているかどうか）。 プログラミングコンセプトが構築コンセプトにどのように似ているかについて、説明または個人的な経験を提供してください。 [ アイデアに対する芸術と人文科学から得られたクレジットからプログラミングへの概念 ]

31 design  architecture  development-process