タグ付けされた質問 「business-logic」

私は、ほとんどのビジネスロジックがデータベースに実装されているプロジェクト（主にストアドプロシージャを使用）で働いてきました。一方、仲間のプログラマーからは、これは悪い習慣だと聞いたことがあります（「データベースはデータを保存するためにあります。アプリケーションは残りを行うためにあります」）。 これらのアプローチのどれが一般的に優れていますか？ 私が考えることができるDBにビジネスロジックを実装することの長所は次のとおりです。 ビジネスロジックの集中化。 アプリケーションの種類、プログラミング言語、OSなどの独立性。 データベースは、テクノロジーの移行や大きなリファクタリング（AFAIK）を受けにくい傾向があります。 アプリケーションテクノロジの移行に関する手直しはありません（例：.NETからJava、PerlからPythonなど）。 短所： SQLは、ほとんどのアプリケーション指向言語が提供するライブラリと言語構成の欠如により、ビジネスロジックプログラミングの生産性が低く、より複雑です。 ライブラリ経由でのコードの再利用がより困難です（可能な場合）。 生産性の低いIDE。 注：私が話しているデータベースは、SQL Server、Oracle、MySqlなどのリレーショナルで人気のあるデータベースです。 ありがとう！

107 database  application-design  business-logic  business-rules 

私は常に、ビジネスロジックはコントローラー内になければならず、コントローラーは「中間」部分であるため、静的のままであり、モデル/ビューはインターフェースを介してカプセル化する必要があると考えていました。そうすれば、他に何も影響を与えずにビジネスロジックを変更し、複数のモデル（データベース/ストレージのタイプごとに1つ）および多数のビュー（たとえば、異なるプラットフォーム用）をプログラムできます。 この質問で、ビジネスロジックを常にモデルに配置する必要があり、コントローラーがビューと深く関係していることを読みました。 私にとって、それは本当に意味をなさないし、別のデータベース/ストレージのタイプをサポートする手段を持ちたいと思うたびに、ビジネスロジックを含むモデル全体を書き直さなければならないことを意味します。 また、別のビューが必要な場合は、ビューとコントローラーの両方を書き換える必要があります。 誰かがそれがなぜであるか、または私がどこかで間違った場合に説明してもらえますか？

70 mvc  business-logic 

データフォームを介してデータベースにレコードを追加する簡単なMVC Javaアプリケーションを作成しました。 私のアプリはデータを収集し、検証して保存します。これは、データがさまざまなユーザーからオンラインで調達されているためです。データは本質的にほとんど数値です。 データベース（SQLサーバー）に格納されている数値データで、計算を実行して結果を表示するアプリを作成します。ユーザーは計算の実行方法に関心がないため、カプセル化する必要があります。ユーザーは、単純な計算データ（たとえば、A列データからB列データをC列データで除算したもの）のみを表示できる必要があります。同じストアドプロシージャを記述する方法は知っていますが、3層アプリが必要です。 データベースにレコードとして入れて、計算を実行して処理したデータが必要です。元のデータは影響を受けないまま、計算後の新しいデータは新しいエンティティレコードとしてデータベースに保存する必要があります。 このバックグラウンド計算用のコードはどこに書くべきですか？ルールとビジネスロジックなので、新しいJavaBeansファイルに入れる必要がありますか？

44 web-development  mvc  object-oriented-design  business-logic 

データベースはデータレイヤーに属しているのに対し、ストアドプロシージャはビジネスロジックであるため、データベース内のストアドプロシージャにビジネスロジックがあると、3層分離アーキテクチャに違反するという話を私の同僚から受けました。 ストアドプロシージャがなければ、世界は非常に厳しい場所になると思います。 彼らは本当に3層分離に違反していますか？

41 business-logic  n-tier  layers  stored-procedures  separation-of-concerns 

Django / Python / Web Developmentを学び始めたばかりです。この問題は、しばらく私を悩ませてきました。 Djangoで複数のテンプレートを使用してアプリケーションを作成しています。私は、基本的にそれぞれのテンプレートへの応答をレンダリングするだけのviews.pyを持ち、DBを構造化したmodels.pyを持っています。テンプレートの1つで、画像をアップロードする必要があります（実行できます）。アップロードされた画像の機能に基づいたロジックを実行する必要があります（まだ実行されていません）。このロジックには、多くの重い計算が含まれます。計算の実行後、ロジックは処理済みの情報（座標）をテンプレートに返す必要があります。 pythonファイルを次々に呼び出すスタンドアロンのPythonデスクトップアプリケーションで、これらすべてのアクションを正常に実行できました。ただし、これをWebアプリケーションにしたいので、Djangoフレームワークの使用を開始しました。 私は多くの検索を行いましたが、すべてのロジックを含むこのPythonファイルをどこに正確に配置すべきかをまだ理解できていません。別のクラスベースのファイルが(logic.py)あり、それを呼び出す必要がありview.pyますか？グーグルで調べたところ、多くの開発者がDjangoのmodels.pyにビジネスロジックを配置していることがわかりました。ただし、モデルはバックエンドと排他的に通信する必要があるため、直感的には正しくないと感じています。助けていただければ幸いです。事前に感謝します。

26 python  django  templates  business-logic  view 

職場やオンラインでビジネスロジックについて多くの人が話しているのを聞いたことがあり、このサイトに関するいくつかの質問を読んだことがありますが、この用語はまだあまり意味がありません。たとえば、私がよく見かける（言い換え）ステートメントは次のとおりです。 「ビジネスロジックは、実際のビジネスルールをエンコードするプログラムの一部です。」私が読んだ定義のほとんどは、このような円形のものです。 「ビジネスロジックは、特定のアプリケーションに固有のすべてです。」「特定のアプリケーションはビジネスロジック以外の何物でもない」と、これがどのように異なるかはわかりません。したがって、質問のタイトル。 「データアクセス層の上とGUI層の下にビジネスロジック層が必要です。」私が書いたコードでは、データベースアクセサーはアクセスするデータを知る必要があり、UIコードはそれを正しく表示するために表示するものについて多くを知る必要があり、その間に実際に行うことは何もありませんクライアントとサーバー間でデータの塊を渡すこと以外の2つの場所。それでは、実際にビジネスロジックレイヤーに入るものは何でしょうか？ 「ビジネスロジックはプレゼンテーションロジックから分離する必要があります。」私たちが受け取る機能要求のほとんどは、ビジネス上の理由でプレゼンテーションロジックを変更することです。ビジネスルールの1つが、デフォルトで32番目の表記で米国国債の価格を表示する場合（ユーザーに構成するためのUIも提供します）、プレゼンテーションロジックは、このルールが完全に実装されていない場合、少なくとも存在することを知る必要があります。また、UXデザインの主要な部分は、ユーザーがソフトウェアが実装しようとしているビジネスルールを理解するのを支援しているようです。 実際にビジネスロジックのみを行うチームに所属していて、非ビジネスロジックはすべて他のチームによって実行されている可能性はありますか？または、個別のエンティティとしての「ビジネスロジック」の概念全体は、特定のアプリケーションまたはアーキテクチャでのみ機能しますか？ 答えを具体的にするために：ドミノのピザアプリを再実装する必要があると仮定します。ビジネスロジックとは何ですか？また、そのアプリの非ビジネスロジックとは何ですか？そして、ピザ情報のほとんどがデータアクセス層とプレゼンテーション層に流出することなく、ピザの注文ビジネスロジックを独自のコードの「層」に配置するにはどうすればよいでしょうか。 更新：私のチームはおそらく90％のUIコードを実行しており、ビジネスロジックと呼ばれるものの大部分（すべてではない）が他のチームまたは企業から来ているという結論に達しました。基本的に、私たちのアプリケーションは監視用です財務データ、およびほとんどすべての機能は、ユーザーが表示するデータと表示方法をカスタマイズする方法です。売買は行われていません（ただし、当社の他のアプリと少し統合しています）が、実際のデータは外部ソースの負荷によって提供されます。しかし、ユーザーは自分の「モニター」のコピーを他のユーザーに送信するなどのことを許可しているので、私たちがそれをどのように処理するかの詳細は、おそらくビジネスロジックとみなされます。実際には、現在バックエンドコードの一部と通信するモバイルアプリがあり、フロントエンドコードのどの部分を理想的な世界（基本的には準MVCのM）でUIと共有したいかを正確に知っています。それが私たちにとってのBLLだと思います。 user61852の答えは、「ビジネスロジック」が何を参照し、何を参照していないかについて、より具体的な理解を与えてくれたので受け入れています。

25 architecture  business-logic  business-rules 

あるデータストアにきめ細かなデータを持ち、分析の大きな可能性を提供し、ビジネス価値を向上させ、必要に応じてパフォーマンスを向上させるために非正規化データを含む読み取りを必要とする柔軟性を備えているため、貧乏人のCQRS 1をかなり長い間適応させてきました。 しかし、残念ながら最初から、このタイプのアーキテクチャにビジネスロジックを正確に配置する必要があるという問題に苦労してきました。 私が理解していることから、コマンドは意図を伝える手段であり、ドメイン自体とは関係がありません。これらは基本的にデータ（ダム-必要に応じて）転送オブジェクトです。これは、異なるテクノロジー間でコマンドを簡単に転送できるようにするためです。同じことが、正常に完了したイベントへの応答としてイベントに適用されます。 典型的なDDDアプリケーションでは、ビジネスロジックはエンティティ、値オブジェクト、集約ルート内に存在し、データだけでなく動作も豊富です。ただし、コマンドはドメインオブジェクトではないため、データのドメイン表現に限定されるべきではありません。これは、コマンドに過度の負担をかけるためです。 本当の質問は、ロジックはどこにあるのでしょうか？ 値の組み合わせについていくつかのルールを設定する非常に複雑な集合体を構築しようとすると、私はこの闘争に最も頻繁に直面することがわかりました。また、ドメインオブジェクトをモデル化するときは、フェイルファーストパラダイムに従い、オブジェクトがいつメソッドに到達するかを知ることが有効な状態にあることを好みます。 集約Carが2つのコンポーネントを使用するとします。 Transmission、 Engine。 両方TransmissionとEngine値オブジェクトは、スーパータイプとして表され、サブタイプ、記載しているAutomaticとManualトランスミッション、またはPetrolとElectricそれぞれエンジン。 このドメインでは、それ自体で生活TransmissionするAutomaticかManual、成功するか、それとも、またはいずれかのタイプEngineが完全に作成されます。しかし、Car集約は該当する場合にのみ、いくつかの新しいルールを紹介Transmissionし、Engineオブジェクトが同じコンテキストで使用されています。すなわち： 車がElectricエンジンを使用する場合、許可されるトランスミッションタイプはのみですAutomatic。 車がPetrolエンジンを使用するとき、それはどちらのタイプも持つかもしれませんTransmission。 コマンドを作成するレベルでこのコンポーネントの組み合わせの違反をキャッチできましたが、前に述べたように、コマンドにはドメインレイヤーに限定されるべきビジネスロジックが含まれるため、実行すべきではないことを理解しているからです。 オプションの1つは、このビジネスロジック検証をコマンドバリデータ自体に移動することですが、これも正しくないようです。コマンドを分解し、ゲッターを使用して取得したプロパティを確認し、バリデーター内でそれらを比較して結果を検査しているように感じます。それは私にとってデメテルの法則違反のような叫びです。 上記の検証オプションは実行可能とは思えないため、破棄することは、コマンドを使用してそれから集計を構築する必要があるようです。しかし、このロジックはどこにあるべきでしょうか？具体的なコマンドを処理するコマンドハンドラー内にあるべきですか？それとも、おそらくコマンドバリデーター内にあるべきでしょう（このアプローチも好きではありません）。 現在、コマンドを使用しており、責任あるコマンドハンドラー内でコマンドから集計を作成しています。しかし、これを行うと、CreateCarコマンドが存在する場合、コマンドバリデータがまったく含まれないため、コマンドバリデータがあれば、別のケースで有効であることがわかっているコンポーネントが含まれますが、集計は異なると言う場合があります。 CreateUserコマンドを使用して新しいユーザーを作成する、さまざまな検証プロセスを組み合わせたさまざまなシナリオを想像してみましょう。 コマンドには、Id作成されたユーザーとそのが含まれますEmail。 システムは、ユーザーの電子メールアドレスについて次のルールを示します。 一意である必要があり、 空にしないでください、 最大100文字（db列の最大長）でなければなりません。 この場合、一意の電子メールを持つことはビジネスルールですが、システム内の現在の電子メールのセット全体をメモリにロードし、コマンドで電子メールをチェックする必要があるため、集約でチェックすることはほとんど意味がありません集合体に対して（Eeeek！何か、何か、パフォーマンス。）。そのため、このチェックをコマンドバリデータに移動します。コマンドバリデータはUserRepository、依存関係として受け取り、リポジトリを使用して、コマンドに電子メールが存在するユーザーが既に存在するかどうかをチェックします。 これに関しては、他の2つの電子メールルールをコマンドバリデーターに入れることは突然意味があります。しかし、ルールはUser集約内に実際に存在し、コマンドバリデーターは一意性のみをチェックし、検証が成功した場合は、User集約を作成CreateUserCommandHandlerしてリポジトリに渡し、保存する必要があると感じています。 リポジトリのsaveメソッドは、集約が渡されるとすべての不変条件が満たされることを保証する集約を受け入れる可能性が高いため、このように感じます。ロジック（空でないなど）がコマンド検証自体にのみ存在する場合、別のプログラマーはこの検証を完全にスキップUserRepositoryして、Userオブジェクトでsaveメソッドを直接呼び出すことができ、致命的なデータベースエラーにつながる可能性があります長すぎました。 これらの複雑な検証と変換をどのように個人的に処理しますか？私はほとんど自分のソリューションに満足していますが、選択肢にかなり満足するためには、私のアイデアとアプローチが完全に愚かではないことを断言する必要があると感じています。私は完全に異なるアプローチに完全にオープンです。個人的に何か試してみて、あなたのために非常にうまくいったことがあるなら、私はあなたの解決策を見たいと思います。 1 RESTfulシステムの作成を担当するPHP開発者として働いている私のCQRSの解釈は、コマンドを同期的に処理する必要があるためにコマンドから結果を返すことがあるなど、標準の非同期コマンド処理アプローチとは少し異なります。

22 domain-driven-design  business-logic  cqrs 

これは私がSOに戻ってしばらく尋ねた質問ですが、ここでよりよく議論されるかもしれません... 私が働いているところで、私たちは何度もこの主題について行き来しており、健全性チェックを探しています。ここに質問があります：ビジネスオブジェクトはデータコンテナ（DTOに似ています）であるか、またはそのオブジェクトでいくつかの機能を実行できるロジックも含まれている必要があります。 例-顧客オブジェクトを取得します。おそらく、いくつかの一般的なプロパティ（名前、IDなど）が含まれますが、その顧客オブジェクトには関数（保存、計算など）も含める必要がありますか？ 1行の推論では、オブジェクトを機能（単一責任プリンシパル）から分離し、ビジネスロジックレイヤーまたはオブジェクトに機能を配置します。 もう一方の推論では、いいえ、顧客オブジェクトがある場合は、Customer.Saveを呼び出して終了します。オブジェクトを消費している場合、顧客を救うために別のクラスについて知る必要があるのはなぜですか？ 私たちの最後の2つのプロジェクトでは、機能からオブジェクトが分離されていましたが、新しいプロジェクトで議論が再び行われました。 どちらがより理にかなっており、なぜですか？

19 business-logic  business-rules 

私は私が移動する方が良いだろう（もしあれば）どのような状況では、コードとEntity Frameworkののメイク使用されているすべての私のビジネス・ロジックを、持っている場合は、いくつかのストアドプロシージャにビジネスロジックを、代わりのコードでそれをすべて保ちますか？ 明確にするために、代わりにではなく、現在のセットアップ（コード内のビジネスロジック）と組み合わせて意味します。ストアドプロシージャですべてのビジネスロジックを使用することの長所と短所を求めている同様の質問を多数見ましたが、ビジネスロジックの残りを保持しながら、エッジケースロジックでストアドプロシージャを控えめに使用することについてはあまり知りませんでしたコードで。 違いがある場合は、MSSQLとEntity Frameworkを使用しています。 これらは、以前にストアドプロシージャを使用したことがある状況です。 実行に数分かかっていた複雑なレポート（これはWebアプリのページでした）。LINQが提供するものよりもはるかに効率的な（実行に数秒しかかからない）SQLを作成できることがわかりました。 Webアプリケーションは、アプリケーションに関係のない他の多くの機密情報を含む別のデータベースのいくつかのテーブルを読み書きする必要がありました。すべてにアクセスするのではなく、必要なことだけを行い、限られた情報のみを返すストアドプロシージャを使用しました。Webアプリケーションは、テーブルなどにアクセスせずに、このストアドプロシージャのみにアクセスできます。 この質問をする前に私が見た他の投稿： ストアドプロシージャは、世界最大のITソフトウェアコンサルティング会社の1つで悪い習慣ですか？ Webアプリケーションのストアドプロシージャにすべてのビジネスロジックを保持することの長所と短所 /programming/15142/what-are-the-pros-and-cons-to-keeping-sql-in-stored-procs-versus-code /dba/2450/what-are-the-arguments-against-or-for-putting-application-logic-in-the-database/2452#2452 ORMを使用せず、ストアドプロシージャを使用する場合

19 design  sql-server  orm  business-logic  stored-procedures 

私は、チューリングマシン（および拡張によりフォンノイマンマシン）が、次のような停止問題を解決できないという現実を受け入れることを拒否する同僚がいます。 あなたは十分な時間とお金で何でもできます。 彼はまた、次のことを主張する理論的な問題を嫌います。 私たちの分野では、これらの質問に出くわすことは決してありません。私たちは理論科学者ではなく、アプリケーション開発者です。 彼にこのことを納得させるために使用できる計算上不可能なビジネス上の問題の良い例はありますか？

17 computer-science  theory  business-logic 

今日、私は組織の別の開発者とデータベースマップクラスにメソッドを追加する場所と方法について、激しい議論になりました。を使用しsqlalchemy、データベースモデルの既存のコードベースの大部分は、クラス名を持つマッピングされたプロパティのバッグ、データベーステーブルからpythonオブジェクトへのほぼ機械的な変換に過ぎません。 議論の中で、私の立場は、ORMを使用する主な価値は、マップされたクラスに低レベルの動作とアルゴリズムを付加できることだということでした。モデルは最初にクラスであり、2番目に永続的です（ファイルシステムでxmlを使用して永続的である可能性があるため、気にする必要はありません）。彼の見解では、すべての動作は「ビジネスロジック」であり、必然的に、データベースの永続化のみに使用される永続モデル以外のどこかに属します。 私は確かにビジネスロジックとは区別されていると思いますが、それは実装方法の下位レベルからある程度分離されているので、分離する必要があります前の段落で議論しましたが、私はそれが何であるかについて指を置くのに苦労しています。私は、彼らがしたいとのAPI呼び出しているユーザーには、（我々の場合には、HTTP「安らか」である、）APIが何であるかのより良い感覚を持っていません、彼らが行うことを許可されているものとは異なった、そしてどのように完了します。 tl; dr：ORMを使用する場合、マップされたクラスのメソッドにはどのような種類の要素を含めることができますか？

16 orm  abstraction  business-logic 

私はそれが高価であることを知っていますが、（IMO）それは非常に良い習慣だと思います。たとえば、営業担当者でない場合は請求書を保存できないなどのルールについて話しているので、その場合は「あなたは許可されていません」などの例外をスローします... 別のアプローチは、ステータスなどのオブジェクトを持つことです 他のアプローチはありますか？それについてどう思いますか？

16 idioms  business-logic  business-rules  rules-and-constraints 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 コーディングプロセス中に非IT担当者がプログラマーと連携する経験はありますか？ それはペアプログラミングのようなものですが、一人はビジネスについて多くのことを知っている非ITの人です。おそらく、物事の計算方法を知っており、非慣用的な手続きコードを理解できる数学のバックグラウンドを持つプロセスエンジニアです。 PL / SQLのような手続き型のドメイン固有言語は、IT以外のエンジニアでも非常に理解しやすいことがわかりました。これらの人物は最終的にコードの共著者となり、式、要因などの正確性を保証します。 この種のペアプログラミングは非常に生産的であり、この種のエンジニアリングタイプのユーザーは、コードの「所有者」および「作成者」であると感じ、コミュニケーションプロセスの誤解を最小限に抑えます。テストケースの設計にも役立ちます。 この慣習は一般的ですか？ 名前はありますか？ 同様の経験がありますか？

14 teamwork  requirements  client-relations  business-logic  pair-programming 

私は静的型チェックの大ファンです。これは、次のような愚かな間違いを犯さないようにします。 // java code Adult a = new Adult(); a.setAge("Roger"); //static type checker would complain a.setName(42); //and here too しかし、それはあなたがこのような愚かな間違いを犯すことを妨げません： Adult a = new Adult(); // obviously you've mixed up these fields, but type checker won't complain a.setAge(150); // nobody's ever lived this old a.setWeight(42); // a 42lb adult would …

13 business-logic  static-typing  type-safety 

そのため、TDDを介してデータアクセスレイヤーを作成してきましたが、やや懸念がありました。私はむしろ間違った道を進んで行きたくないので、私の考えがきれいなアーキテクチャに沿っているかどうかを確認するように皆さんにお願いしたいと思いました。 私のデータアクセスレイヤー（略してDAL）内のメソッドは非常に単純です。これらはデータベース内のストアドプロシージャと一致しており（これを呼び出して物事をきれいにする方法はありません）、プロシージャと同じパラメータが含まれています。次に、データベースに接続し、クエリ結果を返します。次に例を示します。 public int DeleteRecord(int recordId) { recordId.RequireThat("recordId").NotZeroOrLess(); List<SqlParameter> parameters = new List<SqlParameter>(); parameters.Add(new SqlParameter { ParameterName = "@RecordId", SqlDbType = SqlDbType.Int, Direction = ParameterDirection.Input, Value = recordId}); return this.ExecuteNonQuery("DeleteRecord", parameters.ToArray()); } 私は結果セットで何も意味のあることをしていないので、これはこのタイプのメソッドには完全に機能します。コマンドが機能したことを確認したいだけなので、非クエリの結果、つまり影響を受けた行だけを返し、その番号を使用してロジックを検証できます。 ただし、別のDALメソッドで、レコードをロードしたいとします。マイロード手順が実行されようとしているselectsテーブルの束と戻っに対してDataSet、私はビジネスを作成する必要があり、私のDALは使用方法内のオブジェクトかどうかと戦っていますDataSet、または私のビジネスオブジェクトの場合自身がちょうど持っている必要がありますLoad()取得するメソッドをDataSetDALから、そして基本的にそれ自身を埋めます。 DALを介してそれを行うと、Business Objectsのロジックが少なくなります（これは単なる選択ロジックですが、それでもロジックです）が、DALを少し混雑させて、本当にすべきでないことをしているように感じさせますやってる 皆さんはどう思いますか？

12 c#  .net  architecture  database  business-logic