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

ビジネスロジックでは、次のようなメソッドが定義されている場合があります。 User.ResetCourse(Course courseToReset) 問題は、ユーザーとコースの両方がEntity Frameworkプロキシオブジェクトであるということです。つまり、ユーザーまたはコースのいずれかのナビゲーションプロパティにヒットすると、それらのオブジェクトはIQuery可能ではないため、通常どおりに繰り返されるため、データベースに大きなヒットを引き起こす可能性があります。 これを解決するために、署名を次のように変更しました。 User.ResetCourse(MyDBContext db, Course courseToReset) つまり、データベースに直接クエリを実行して必要な変更を効率的に行うことができますが、データベースコンテキストをビジネスオブジェクトに渡すことは非常に間違っているようです。 その後、ユーザーにサービスレイヤーを移行しました。つまり、次のようなものがあります。 CourseService.ResetForUser(Course courseToReset, User forUser) このサービスには、作成時に挿入されたDBContextへの参照がありますが、現在のビジネスオブジェクトは、動作のない単なるデータバッグです（つまり、Anemic Domain Model）。 どうすればこれを回避できますか？

11 c#  entity-framework  domain-model  business-logic 

私はモノリシックなアプローチに慣れているので、マイクロサービスアーキテクチャに頭を抱えようとしています。 非常に簡素化された Uber予約システムを構築しようとしているとします。：物事を単純化するために、我々は、我々は3つのサービスとクライアントのゲートウェイAPIを持っているとしましょうBooking、Drivers、Notificationと私たちは、次のワークフローを持っています： 新しい予約を作成する場合： 既存のユーザーがすでに予約しているかどうかを確認する 利用可能なドライバーのリストを取得する ドライバーに通知を送信して予約を受け取ります 運転手が予約をピックアップ すべてのメッセージングがkafkaのようなメッセージングバスではなくhttp呼び出しを介して行われるとしましょう。 したがって、この場合、Bookingサービスは既存の予約の確認を行うことができると思いました。しかし、利用可能なドライバーと通知のリストを誰が取得する必要がありますか？ゲートウェイレベルで実行することを考えていますが、ロジックは次の2つの場所に分割されています。 Gateway -利用可能なドライバーのリストを取得+通知を送信 Booking -既存の予約を確認する そして、ゲートウェイはそれを行うのに適切な場所ではないと確信していますが、Bookingサービスでそれを行っている場合、緊密に結合されているように感じますか？ さらに複雑にするために、予約システムを再利用したいが、独自のビジネスロジックを追加した別のプロジェクトがある場合はどうなるでしょうか。新しいプロジェクトゲートウェイが独自のビジネスロジックを既存のものから分離できるように、ゲートウェイレベルでそれを行うことを考えたのはそのためです。 それを行う別の方法は、各プロジェクトがコア予約サービスと通信する独自​​の予約サービスを持っていることですが、ここでの最善のアプローチは何なのかわかりません:-)

11 architecture  microservices  business-logic 

休業。この質問には詳細または明確さが必要です。現在、回答を受け付けていません。 この質問を改善してみませんか？詳細を追加し、この投稿を編集して問題を明確にしてください。 4年前休業。 私がstackoverflowについて同じ質問をしたが、彼らはここで尋ねるように指示したことに注意してください。 アプリケーションロジックとビジネスロジックの違いを識別しようとしていますが、一連の記事を見つけましたが、残念ながらそれらには矛盾があります。 ここ では彼らは同じであると言いますが、ここでの答えはまったく異なります。 私には次のように理解しています。 LogicGoogleで単語の定義を調べると、 特定のタスクを実行するためのコンピューターまたは電子デバイスの要素の配置の基礎となるシステムまたは一連の原則。 したがって、ロジックがその場合、set of principles underlying the arrangements of elementsビジネスロジックはであるset of principles underlying the arrangements of the business rules必要があります。つまり、システムを取得するために従うべきルールがビジネスニーズを反映していることを意味します。 そして、私にとってのアプリケーションロジックはthe principles that the application based on、言い換えると、これらのルールを適用してシステムにビジネスニーズを反映させる方法です。たとえば、MVCを使用すべきか、使用すべきでないか、SQLまたはMSSQlを使用すべきかなどです。 ですから、アプリケーションとビジネスロジックの違いに関する混乱を取り除くために誰かが私を助けていただけませんか。

11 business-logic  business-rules 

Webアプリケーションの一般的なスタックは、データベース、サーバーサイドコードを備えたサーバー、HTML / CSS / JavaScriptを備えたブラウザーを備えたユーザーです。 広範なAJAXが登場する前は、コントローラーがサーバー側コードであるMVCが決着していました。サーバーは動的Webページ（つまり、JSPやASPなどのテンプレート化されたHTMLソリューション）に対する応答要求をルーティングする必要がありました。サーバーは、データベースへの呼び出しを調整し、ページ要求への応答に使用する動的ページを決定します。これらすべての結果、ビジネスロジックはページを提供するという考えに強く結び付けられていませんが、サーバーには最終的にビジネスロジックが含まれています。 「Web 2.0」に移行すると、サーバーサーバーの静的ページは、JavaScriptを使用してデータを入力し、表示内容を変更します。JavaScriptに含めることができます。JavaScriptは多くの場合、RESTfulサービスを実装しています。つまり、データベースクエリを指定しています。 したがって、サーバーは、実際のファイルを提供し、AJAX呼び出しに応答する役割に任されています。また、AJAX呼び出しへの応答は、セッション管理とセキュリティの提供にすぎません。そして実際、ユーザーが見ることができるのは、データベースで指定されるべきデータです。 そこで、そこから、サーバーを、電子メールの送信やWebサービスの起動など、たまにしか行わない、ダムの仲介者の役割に追いやるべきですか？ビジネスロジックがすべてJavaScriptに存在する（秘密でない場合）か、それがストアドプロシージャに存在する可能性がありますか？ サーバーとデータベースを組み合わせたり、SAPのようなERPソリューションをサーバーとして機能させることは理にかなっていますか？

10 ajax  server-side  business-logic 

初期化、入力、出力を処理しないプログラムの一部があるとします。何をすべきか、何を許可するか、または許可しないかを指定するだけです。これには「ビジネスロジック」という用語を使用します。しかし、アプリケーションはビジネスとは何の関係もありません。 例：ゲーム。次の部分があるとします。 入力処理 衝突検出、物理、プレーヤーコントロール 出力のレンダリング AI-NPCは指定された目標をどのように達成するか。 「ビジネスロジック」-プレーヤーが特定のオブジェクトに触れるとどうなるか。どのような種類のNPCが存在し、どのような場合に何が行われるか、「ライフ」、「弾薬」、「レベル」、「スコア」の概念。 しかし、それはビジネスではなく、単なるゲームです。ウィキペディアはそれについて明確ではありません。

10 terminology  business-logic 

私はこの答えを読みます：https : //softwareengineering.stackexchange.com/a/234254/173318私の理解を訂正してください。 ビジネスルールとは、現実の世界でのビジネスのステップのリストを指します（コードなし）。 ビジネスロジックは、ビジネスルールをコードに変換するプロセスと、「ビジネスロジック」と呼ばれるこれらのコードの束/種類を指します。 また、サービス層は何に使用されますか？私がこの答えを読んだ場合、それはビジネスロジックと同じように聞こえますhttps://stackoverflow.com/a/4817935/4190539 サービスレイヤーは、ビジネスロジックとリポジトリが出会う場所ですか？

9 design-patterns  object-oriented-design  business-logic 

この質問を投稿する前に、いくつか調査を行いました。他の質問や投稿の中で、そのうちの1つを以下に示します。どのように判断するか明確な心がつかめなかった。 データアクセス層内のビジネスオブジェクト リポジトリがあり、ビジネスレイヤーはリポジトリを呼び出してデータを取得します。たとえば、BLLとDALの次のクラスがあるとします。 class BllCustomer { public int CustomerId {get; set;} public String Name {get; set;} public BllAddress Address {get; set;} } class BllAddress { public int AddressId {get; set;} public String Street {get; set;} public String City {get; set;} public String ZipCode {get; set; } } class DalCustomer { …

9 c#  architecture  .net  database  business-logic 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 5年前休業。 私は過去数ヶ月間、ZendのMVC実装と組み合わせてOOPを研究してきました。私は一般的に、プログラミングにはかなり新しいですが、私は物事に必ず私が理解することを意味私のための「正しい」方法で、学ぶべきだと強く感じ、なぜ物事は彼らが道をやっているし。つまり、何かを行う方法（何かを言う、音楽など）を学ぶ上で、何かを行う方法を学ぶ最善の方法は、そもそもなぜそのように行われるのかを知ることであることがわかりました。 とにかく、私は自分のビジネスモデル（つまりMVCのM）を開発する方法を理解するのに非常に苦労してきました。OOPを一般的に理解していないからではないと判断しました。数ヶ月、私は概念を理解することは非常に難しいとは思いません。私が研究した例は、実際には非常に直感的です。私の問題は、私自身の問題をオブジェクト指向のソリューションに変換するプロセスにあると思います。本の例（私がこれまでに読んだもの）は明白すぎるため、問題をオブジェクトに変換するプロセスはそれほど難しくありません。私が見落としているのは、高レベルの抽象化されたプロセスです。すべてのオブジェクト指向ソリューションが最高レベルで回答する必要があるステップまたは質問のある種のリスト。 このようなプロセスを5ステップ以内で説明する必要がある場合、それらはどのようなもので、その理由は何ですか。問題をオブジェクト指向のソリューションに変換する最も効果的なプロセスは何ですか？

9 object-oriented  mvc  domain-model  business-logic 

私はかなり前からコマンドパターンを使用していますが、実際にExecuteメソッドにどれだけのロジックを入れることができるか本当にわかりません。 コマンドパターンの現在の実装は次のようになります。 public abstract class Command { public static event EventHandler Completed = delegate { }; public bool Success { get; private set; } public Exception Exception {get; private set; } public abstract bool Execute(); protected bool OnCompleted(bool success, Exception ex = null) { Success = success; Exception = ex; …

8 design-patterns  unit-testing  business-logic  implementations 

私の質問は、Stack Overflowでのこれと同様です。ビジネスレイヤー内で作業ユニット/リポジトリを使用する正しい方法は何ですか？ シナリオ： .Netソリューション DBからオブジェクトを取得するために使用されるIRepository IUnitOfWorkを使用して複数のリポジトリ間でトランザクションを許可 これは私には理にかなっていて、私はこれらの線に沿ってうまく機能する何かを実装しました。ここで、ビジネスロジックレイヤーを紹介したいと思いますが、3つの要素（BLL、UnitOfWork、およびリポジトリ）を整理することに頭が悩んでいます。 私の理解： リポジトリ-データの取得、操作 UnitOfWork-永続性 BLL-ビジネスに関連するロジック（「現実世界」）（その用語は嫌いです！） ASP.Net MVCフロントエンドがあるとします。 BLLはどのように見え、それを使用するMVCコントローラーはどのように見えますか？ 参考までに：私のIUnitOfWork / IRepository実装が私の混乱の根本的な原因であるのではないかと思います。 public class IRepository<T> { private IObjectSet<T> objSet; public IRepository<T>(IUnitOfWork uow) { objSet = uow.CreateObjectSet<T>(); } public IQueryable<T> Add(T entity) { objSet.Add(entity); } //etc. etc. for delete, attach, getall } したがって、BLLがある場合は、それをIUnitOfWorkに渡して、必要なIRepositoryインスタンスを作成できるようにする必要があるように感じます。しかし、BLL（フロントエンドとは別のDLL）は、ビルドするIRepositoryの実装をどのように「認識する」のでしょうか。

8 architecture  business-logic  unit-of-work  repository-pattern 

私は現在、ソフトウェア開発者として働いており、ソフトウェア工学の学位を取得しています（前者は後者を行いません）。 私は自分の能力を十分に発揮できると確信していますが、もっと上手にできると感じています。私の最大の落とし穴は私のビジネススキルにあることを知っています。たとえば、なぜそのような方法で何かを実装するように求められるのか、最初はよくわかりません。その背後にあるビジネス要件を理解していないためです。 私のビジネススキルを向上させる上で何か良いアドバイスはありますか？それとも経験に伴うものですか？

8 requirements  business-logic