問題タブ [business-logic]

Linq To Sqlによって生成されたクラスを拡張して、新しいオブジェクト（= row）が作成されたときに初期化したいと思います。

親行が作成されたときに子テーブルに行を追加したい。

Oncreated（部分）メソッドを使用して次のようなことをしたいと思っていました。

OnCreatedは、コンストラクターから毎回呼び出されます。したがって、OnCreatedの呼び出し後にオブジェクトがデータベースからロードされる場合も同様です。また、オブジェクトがデータベースからロードされている場合は、コードを実行しないでください。

では、オブジェクト（-graph）を初期化するために、モデルにロジックをどこに追加できますか？

[バックグラウンド]

ここに来る前に書かれた C# アプリケーションがあります。現在、私は開発組織には属していませんが、インターネット マーケティング組織内のサブグループで技術リーダーを務めています。私の責任は、プロセスの自動化、最小限のデスクトップ サポート、そして私たちの生活を楽にするカスタム アプリです。

[/バックグラウンド]

【アプリ詳細】

URL のリストからカスタム データベース ファイルを作成するアプリがあります。これらの種類の db ファイルを使用する 2 つのアプリケーション用に、1 つの入力ファイルと 2 つの出力ファイルを持つように設計されています。2 つの出力ファイルの違いに関するルールは、コードにコンパイルされます。

[/アプリの詳細]

内部 C# アプリは、再構築しないと変更できないビジネス ロジックを使用してコンパイルする必要がありますか?

ビジネス ロジックの実装に現在使用しているソフトウェアは何ですか?

POJOとEJB（2.0）を使用してJavaで実装された非常に重いビジネスロジックを持つアプリがあります。

ビジネス ロジックのコーディングに使用するのに有利な最近のソフトウェア言語またはツールはありますか?

アプリケーションをいくつかのレイヤーに分離したサービス指向システムを構築しています。

1. SOAP Web サービス (例: BuildingService.asmx)
2. ビジネス ロジック層 (BuildingXXX など)
3. データ アクセス層 (例: BuildingProvider)
4. タイプ (例: 建物)

SOAP Web サービスは、SOAP Web サービスから実装を除外するために、ビジネス ロジック層から BuildingXXX タイプのオブジェクトをインスタンス化するだけです。次に、BuildingXXX はデータ アクセス レイヤーの BuildingProvider を使用して、データ転送オブジェクト レイヤーで定義された型を返します。

ビジネス ロジック層のオブジェクトを何と呼ぶべきかを判断できませんでした。

これらのビジネスレベルのエンティティに名前を付けるための「標準」の命名規則は何ですか?

API インターフェイスを提供する製品を開発しているため、他の開発者は主要な製品の一部の機能を使用できます。

これはすでに実装され、文書化されています。

しかし、これが非常に役立つかどうかはわかりません。ドキュメントは開発者にとって非常に明確です。

この機能をレビューする人をどのように見つけることができますか? それはどのようなタイプの人であるべきですか？

ある意味では、単一の機能/コンポーネントのプロダクト オーナーを探しています。出来ますか？

ストアド プロシージャにすべてのビジネス ロジックを備えた CRUD を多用する ASP.NET アプリケーションがあります。

例として、最大 500 行の長さで、複数のテーブルと UDF を参照する大量の条件付きロジックを含む UPDATE ストアド プロシージャがあります。proc は、更新されるフィールド名と新しい値を受け取り、一連の宣言された変数を設定し、一連の検証を行い、更新を行う動的 SQL ステートメントを作成します。一度サイズがすべてに収まります。大きくて紛らわしいです。

ビジネス ロジックを .NET 側に移動して、管理/更新、テスト、およびソース管理を容易にしたいと考えています。

私の質問はこれです: このビジネス ロジックはどこに行くべきですか?

「Factory」というプロパティを持つ PurchaseOrder オブジェクトがあるとします。工場が変更された場合、割り当てられた新しい工場が PurchaseOrder にある製品を製造していること、価格が設定されていること、その工場に基づいて要求された最小数量があることなどを確認する必要があります。これらすべての検証には、データベース。

PurchaseOrder オブジェクトの Factory セッターに、汎用データ アクセス オブジェクトへの複数の呼び出しを行う「isFactoryValid」メソッド/プロパティを介してデータ検証を行う責任を持たせ、そうであれば更新を行う必要がありますか?

それとも、PurchaseOrder 関連のデータ アクセスのみを処理する、PurchaseOrder/Database 'proxy' オブジェクトを作成しますか。この場合、PurchaseOrder の setter によって呼び出される「isFactoryValid」メソッドをプロキシに配置し、次にプロキシの update メソッドを呼び出しますか?

これらすべての余分な呼び出しでデータベースへのトラフィックが増加することを心配する必要があるかどうかを判断するにはどうすればよいですか?

複数のビジネスコンポーネント（顧客アプリケーション、ネットワーク、支払いなど）間の要求を仲介する大規模なミドルウェアインフラストラクチャがあるとします。ミドルウェアスタックは、オーケストレーション、ルーティング、変換、およびその他のものを担当します（GregorHohpeによるEnterpriseIntegration Patternsの本と同様）。

私の質問は、ミドルウェアにビジネスロジックを配置するのは良い設計ですか？

私のアプリAがミドルウェアからいくつかの顧客データを要求するとします。ただし、このデータを取得するには、顧客IDとその他のパラメーターを指定する必要があります。このパラメーターのフェッチは、要求元のアプリが行う必要がありますか、それともミドルウェアが顧客IDを受け取り、他のパラメーターを内部的にフェッチするインターフェースを「促進」して提供する責任がありますか？

これは（ビジネスロジックの定義のために）単純な質問ではないことは理解していますが、それが一般的なアプローチなのか、それともいくつかのガイドラインなのか疑問に思いました。

NHibernate.Validator で使用される検証方法 (businbess ルールの検証用) を定義することは可能ですか? EntLib に存在するものを意味します。